heldevia
In the fieldJuly 22, 20269 min read

AI-generated renovation quotes: the hard part wasn't the AI

A Swiss renovation-quoting platform generates complete documents in minutes — AI even built its service catalogue. What takes months is making that catalogue true: validation by the domain expert. An honest account of a pilot phase.

Also available in: Français

A serious renovation quote, in French-speaking Switzerland, means hours of work: re-reading the enquiry, analysing the photos, choosing the line items, calculating quantities, applying the right rates, writing it up properly, laying it out. A platform we built — a renovation-quoting SaaS for the Romandy market, whose name we'll keep to ourselves — does that work in a few minutes, end to end.

And yet it has not launched commercially. For several months it has been in the hands of its client zero, in a pilot phase. That gap is neither a failure nor a secret: it is the least spectacular and most instructive part of the project. This article tells both stories — what AI did disconcertingly fast, and what no AI will ever do in our place.

What AI did fast

Two things, and the second is more surprising than the first.

The first: the software. A pipeline of eight specialised agents — qualifying the enquiry, profiling the client, analysing the photos, resolving materials, calculating, drafting, quality control, generating the final document as PDF and Word. It works today, from the client's free-text request to the laid-out document.

The second: the starting data. The catalogue of roughly 140 service codes, the materials, the recipes linking them — that foundation was built with AI's help in a few days, where assembling it by hand would have taken weeks. It is a plausible, coherent, complete catalogue.

It is also precisely where the real story begins: plausible is not true. We come back to that below — first, let's look at how the system is built, because those architecture choices are the precondition for everything else.

Rule number one: the model never sets prices

The project's structuring decision fits in one sentence: the language model describes; a deterministic engine calculates.

The pipeline strictly separates two families of components. On one side, the "creative" agents — the ones that interpret the enquiry, analyse the photos, adapt the tone, draft the quote's text. They are the ones using a large language model (LLM). On the other, the pricing engine: classic code, documented as "100% reproducible: same input → always the same output", working in decimal arithmetic with explicit rounding rules.

Concretely, the selling price starts from a market price per service and applies multipliers configured in the database: client segment, surface condition, site access, urgency, regional adjustment by canton, project size. In parallel, a cost-of-work calculation (materials, labour hours, overheads, contingency) produces the real margin of each quote, with alert thresholds that flag a critical margin before anything goes out. Three price scenarios — low, medium, high — come out of that engine.

And the model in all this? It gets a voice, not the last word: a "pricing adviser" agent recommends one of the three scenarios per line, with its justification and its confidence level. The recommendation is shown to the human. The amount always comes from the engine.

The Swiss format is not a detail: amounts as CHF 8'450.00, dates as DD.MM.YYYY, VAT at 8.1%, formal address throughout. All of that lives in versioned prompts — we'll come back to those.

Guardrails, not trust

An LLM in production rarely lies out of malice, but it improvises gladly. The system starts from the principle that every model output is suspect until proven otherwise:

  • Qualification is bounded by the catalogue. The agent that turns the client's free-text request into quote lines can only choose among the existing service codes. Its output goes through a deterministic validation: a code that doesn't exist is rejected — that is our anti-hallucination —, a zero or negative quantity is corrected automatically, a duplicate is merged.
  • Repair is bounded too. If validation fails on errors that can't be fixed mechanically, the model gets one repair call. One. If the repair doesn't improve things, we keep the auto-corrected version. No infinite loop burning tokens.
  • The parser doesn't trust the format. Models return JSON… most of the time. The parser tolerates markdown wrappers, extracts the useful block, then validates the structure against strict schemas. A truncated response (token limit reached) is detected and triggers conservative defaults rather than a risky parse.
  • Failure is a nominal case. Retries with exponential backoff, a circuit breaker per model (five consecutive failures open the circuit for five minutes), provider throttling instructions respected. Every invocation — successful or not — is persisted and audited, with cost-anomaly detection that warns at 2× the 30-day average and alarms at 5×.

Model-independent, by construction

Second structuring decision: no agent is married to a model. The agent → model assignment lives in the database, not in the code. The platform speaks to three interchangeable model providers, and changing an agent's model is a configuration operation, not a deployment.

That freedom serves the system's economics first: simple tasks run on economical models, complex qualification on a powerful one — the price gap between the two ends of our grid is two orders of magnitude, so choosing per task is not a refinement, it is the budget. It then lets us compare providers in real conditions (weighted A/B tests) instead of taking public benchmarks at their word. One concrete lesson along the way: the most powerful reasoning models can take over a minute on a long prompt; we split qualification into two shorter phases precisely because of that.

Prompts follow the same discipline as code: stored in the database, versioned through migrations, cached, and failing loudly if a prompt is missing — never a silent default. The catalogue injected into the context is sanitised and size-capped, and user-entered fields go through injection-pattern detection before they reach the model.

The human at the two places that matter

The pipeline can run automatically end to end. In the pilot phase, it stops by default at two points:

  1. After the calculation: price review. The professional sees the three scenarios, the adviser's recommendation and the margin alerts — and decides.
  2. After the drafting: content review. The text is read before it becomes a document meant for an end client.

This is not decorative distrust. It is a principle: AI prepares, the professional signs. Keep it in mind — it is about to change scale.

The real bottleneck: making the catalogue true

So here is a system that generates complete quotes, with a catalogue AI built in a few days. Why hasn't it launched?

Because an AI-generated catalogue is generic. It says a square metre of paint costs this much, that redoing a wall follows that recipe, that an hour of installation covers such a surface. That is plausible — it is even solid synthesis work. But a quote that goes out to an end client doesn't commit a market average: it commits this specific professional — their prices, their suppliers, their way of working, their margins. Every service code, every recipe, every productivity rate must be confronted with the company's reality — validated, adjusted or replaced.

And that validation, no AI can do: the ground truth is written nowhere. It lives in the head of the domain expert. And that expert's hours are the scarcest resource of the project — their work is on building sites, not in a spreadsheet. So the curation advances at the pace the trade allows it to: in bursts, for months. That was predictable, and it is ours to plan for — not theirs to apologise for.

You will recognise the pattern: it is the same principle as the pipeline's two reviews, at a different scale. At runtime, AI prepares a quote and the professional signs it. At project level, AI prepares a catalogue — and it waits for the expert's signature to become true. AI compresses construction; it does not compress validation. The critical path of an enterprise AI project is not in the code: it is in the expert hours needed to anchor the system in reality.

The numbers

What we measureValue
Generating a complete quote (measured in pilot)A few minutes, versus several hours by hand
Building the initial catalogue with AIA few days
Validating the catalogue with the expertOngoing for months — the critical path
Specialised agents in the pipeline8
Service codes in the catalogue~140
Repair calls allowed per qualification1
Circuit breaker per model5 failures → circuit open for 300 s
LLM cost-anomaly alert2× the 30-day average (critical at 5×)
Automated backend testsOver 2,600
Interface languages6

What we would do differently

Transparency is our trademark, so here are the scars — starting with the most important one:

  • Treat expert validation as a contractual deliverable, from day one. We planned the development carefully and left the catalogue curation as an open-ended phase, as if it would happen by itself. It became the critical path. Next time: expert hours committed in the contract, validation sessions on a cadence, and a product that makes that validation as cheap as possible for someone whose day happens on a building site.
  • Business parameters were hard-coded. VAT, rounding rules, margin thresholds lived in the pricing engine's code. They are configurable per tenant today, but the migration cost a full work stream. Any number a client might one day want to change is born as configuration, not as a constant.
  • The first orchestrator did too much. It executed the agents' logic instead of delegating it. We rebuilt it as chains of asynchronous tasks — it is documented in an architecture decision — and the pipeline gained error recovery and the human review pauses. Designing the orchestration as tasks from day one would have avoided the rebuild.
  • Client disconnections taught us streaming. A client closing their tab during an event stream can, depending on the HTTP stack, interrupt in-flight operations and leak database connections. The fix reaches into the framework's internals — the lesson, though, is simple: test the client's brutal disconnection as early as you test the happy path.

Building an AI product that prepares real commercial documents, in French, with amounts in Swiss francs, is nothing like the demos. What will make this system worthy of trust on launch day is not the model: it is the separation of responsibilities, the validations, the bounds, the audit — and the human signatures, from the individual quote up to the entire catalogue. That is exactly what we build for our clients.

Frequently asked questions

Can an AI set reliable prices?
Not on its own — and in our view it shouldn't. A language model is excellent at interpreting a request and writing; it is non-deterministic by nature, which is disqualifying for a commercial calculation. Our answer: the model qualifies and describes, and a separate, 100% reproducible calculation engine sets the price. Same input, same quote, every time — and every amount can be explained line by line.
Why does an AI project take months to reach production?
Rarely because of the model. In our experience, AI compresses construction — the software, and even the creation of the starting data. What it does not compress is validation: checking that every price, every recipe, every assumption matches the reality of the company that will use it. That validation requires the domain expert's hours, the scarcest resource of the whole project. Budget it as a deliverable in its own right, from the contract onwards.
What happens when the model gets it wrong?
It is planned for, not hoped against. Every output goes through deterministic validation: a non-existent service code is rejected, an aberrant quantity is corrected, a truncated response triggers conservative defaults. One repair loop is allowed — exactly one. And the pipeline stops at two points for human review: after the price calculation and after the drafting. A model error costs a correction, never a wrong quote sent to a client.
Do you need to fine-tune a model for this kind of project?
We didn't, and nothing demanded it. Prompts versioned like code, a service catalogue that bounds the answers, deterministic validation on output and the ability to compare several model providers give us more control than a fine-tuned model — which would have frozen the state of the art of six months ago and created a costly dependency to maintain.
How long does generating a quote take?
A few minutes, measured in the pilot phase — versus several hours of manual work for a comparable quote. Latency depends on the chosen model: the most powerful reasoning models can exceed a minute on a complex request, which pushed us to split qualification into two shorter phases. Speed is a parameter you tune — reliability is not negotiable.

All articles

Ready to transform your business with AI?

Let's discuss how intelligent solutions can drive your next competitive advantage.