
AI-assisted commercial offers
Putting AI to work on pre-sales decisions, from analysing a tender to drafting the proposal.
Tech Lead
- NestJS
- TypeScript
- Next.js
- RAG
- PostgreSQL
- pgvector
- Langflow
- Azure
- adoption after 4 months
- 70 %
- release to production
- 1 / mois
- response-time cut
- -25 %
The context
- Pre-sales runs by hand: email threads and Excel files, with nothing centralised.
- Everyone writes proposals from their own past offers alone, without seeing the rest of the department's.
- There is no time to work out the response strategy for a tender.
- The project already exists, but it moves at a crawl and barely reaches production.
My mission
- Taking over as tech lead on a project at a crawl, back in production within the first week, then a release a month.
- Defining the architecture, on the code side and the infrastructure side.
- Arbitrating technical decisions and reviewing pull requests.
- Writing the technical documents and the business impact analysis (BIA).
- Orchestrating two applications and two developers, a senior on the portal, an apprentice on the AI engine.
- Interfacing with the business, with a say in the makeup of the team.
Decisions and trade-offs
- 01
Bringing vector search into the database rather than a managed service
ProblemSearch runs on a managed service, which does not comply with the mandated LLM provider and costs a lot even at low usage.
SolutionMoving storage and search to PostgreSQL and its pgvector extension. An external service still produces the embeddings, through an interface the company provides that guarantees data never leaves the infrastructure.
Why this choiceData governance comes first: keeping embeddings and search in the in-house database clears the compliance point, a precondition set before any launch of the AI part, and reusing Postgres avoids the cost of an underused dedicated service. In exchange, vector search is ours to operate and tune.
- 02
Indexing by chapter rather than by tokens
ProblemThe first version splits documents by tokens, which fragments coherent sections and blurs retrieval.
SolutionSplitting by business section, enriched with metadata (client, sector, type). Retrieval first filters on those structured criteria, then ranks by semantic similarity.
Why this choiceA few meetings with the business showed that the relevance of a past offer rests first on structured criteria, ahead of semantic proximity. The structured filter also makes the result explainable and offsets the absence of a dedicated vector index.
- 03
Handing prompts to the business as versioned data
ProblemA use case's prompt is deeply business data, yet changing it takes a developer and a redeployment.
SolutionPrompts live in a versioned store; a senior bid manager edits them in a dedicated interface, tests them, then promotes them to production himself. Every version stays traced and rolls back in one click.
Why this choiceMaking the business autonomous over its own data shortens the iteration loop and pulls it into quality. The risk of breaking what works stays contained by traceability, instant rollback and user training.
What this project gave me
- Taking over a slowed-down project and getting back to production in a week, then on a monthly cadence.
- Leading each profile differently: light arbitration with a trusted senior, close support for an apprentice.
- An architecture decision under a governance constraint, set as a precondition to launching the AI part.
- Designing a hybrid retrieval engine, structured and semantic, in a single database.
- Giving the business autonomy over technical data, with traceability and rollback.
- Producing the business impact analysis (BIA) and making FinOps calls on the services chosen.
In hindsight
- Move the long, occasional AI workflows to serverless (Durable Functions), where cold start stays negligible against response times measured in seconds.
- Tool the corpus pre-ingestion to speed up how it is filled, too slow today.