Most conversations about AI and forfait bidding — the fixed-price, lump-sum model that still dominates European IT services — end at the same slogan: AI makes proposals cheaper. It does. The slogan just skips the two questions that actually matter: cheaper how, and cheaper at whose expense.
I've sat on both sides of a fixed-price negotiation — as the vendor defending a number, and earlier in my career, as the client rejecting one — across five different delivery organisations. What follows is the cleanest example I've come across of the gap between decorating an old delivery model with AI and genuinely redesigning it: one bidding sequence, run with AP Advisory, for a European energy group I'll call EnergIQ. Same scope, three quotes, a few months apart in 2026. The client turned down the first two on price. The third came back smaller because the delivery model underneath it had been taken apart and rebuilt. Most of what's worth learning here sits in the gaps between those three numbers, not in any one of them.
The brief
EnergIQ's platform — Atlas, internally — handles regulated financial and compliance processes across several legal entities in the group. It works. Everything under it is close to end of support: the operating system, the Java runtime, the web and application servers, and a front end built on ExtJS, a framework that predates Angular and React and that almost nobody starts new interfaces with today.
A 2025 feasibility study had already closed off the cheap option. Patching the existing stack would have cost roughly what a rewrite costs, and delivered none of a rewrite's upside. So Atlas had to be rebuilt on Java 21 / Spring Boot and Angular, migrated module by module against a system that could never go dark, and kept talking to half a dozen upstream and downstream systems throughout.
So far, an ordinary legacy-modernization brief — I could have written this paragraph about half a dozen clients I've worked with since 2013. The pricing conversation is where it stopped being ordinary.
Part I — Two quotes, two rejections
First quote: €2.4M over 24 months
The first proposal was the one most delivery firms would recognize — I've signed off on plenty like it myself: classic Agile forfait, full rewrite, dedicated team, staged phases, standard governance. Around €2.4M over 24 months — a defensible number for the model it assumed.
EnergIQ said it was too expensive. Full stop, no counter-offer. Inside that model there was nothing left to pull except a discount on the same plan, and that's not an answer for a client who has already told you the number doesn't work.
Second quote: €1.7M over 22 months
The second proposal changed the shape of the delivery, not just the price. Instead of a full rewrite: an incremental migration, Atlas and its replacement running side by side behind a routing layer, the new platform taking over module by module, no interruption of service.
AI showed up for the first time — an in-IDE code-completion assistant, laid on top of a delivery process that was otherwise untouched. We kept the productivity assumptions small and checkable: about 10% less effort, about 15% less time, to be validated by an opening proof of concept before the rest of the project was committed. That produced roughly €1.7M over 22 months — a two-month POC plus twenty months of phased delivery.
EnergIQ turned this one down too, and the reason is the part of this story worth keeping. Price was only half of it. The message back was to rethink the governance, the process and the team structure around genuinely new AI techniques — not to preserve the existing model and bolt AI onto it for a productivity bump.
Which was a fair diagnosis, and not a comfortable one to sit with. Adding a code-completion tool to an unchanged delivery model moved the price by 10–15%. That's roughly what AI is worth as an accessory. We hadn't redesigned anything; we'd decorated it.
Part II — Rebuilding the estimate
The third round started from a different question. Not how much faster AI could make our existing process — what the delivery model would look like if it had been designed around AI from day one.
We put together a dedicated AI-delivery team, internally the AI Practice, and paired it with the TMA team already running Atlas in production. That pairing mattered: the TMA team carried the functional knowledge of the platform's compliance rules and edge cases, and no amount of tooling replaces it. Together they re-estimated the whole scope from the underlying functional specifications, feature by feature, inside EnergIQ's own technical environment — Google Cloud Platform, Vertex AI Model Garden with Gemini Flash and Anthropic's Claude models, Google CLI, Cloud Build and Gemini Code Assist.
Working with tools the client had already vetted took a security-approval cycle off the critical path. That's worth more on a bid timeline than most people budget for.
One model per task
The design decision that mattered most — the one I'd tell any CIO to borrow outright, regardless of vendor — was to stop treating "AI" as a single tool. Different steps of the pipeline want different things from a model — depth of reasoning, speed, cost per call — so we matched a model to each step instead of routing everything through one default assistant.
From business needs to deployment — one model or tool per step, not one generic assistant end to end.
| Step | Model / tool | Why this one |
|---|---|---|
| Reading specs | Claude Opus | The functional specifications ran to over a hundred thousand words across two dozen documents. Pulling out clear, cross-checked requirements without losing an edge case needs the deepest reasoning model available — used carefully, because it's also the most expensive. |
| User stories & backlog | Claude Sonnet | Once requirements are structured, turning them into sprint-ready stories is faster, more repetitive work. Sonnet's balance of speed and quality fits, and there's no reason to pay Opus prices for it. |
| Code generation | Sonnet + Gemini Code Assist | In-editor completion handles the day-to-day coding flow. Sonnet takes the bigger scaffolding and module-level generation that needs more context. |
| Code review | Claude Sonnet | Reviewing compliance-sensitive logic needs a model that catches subtle errors, always paired with mandatory human sign-off before anything touching a regulated calculation goes live. |
| Tests & CI/CD | Gemini Flash | Generating and running large volumes of regression tests is mechanical, high-frequency work — where a fast, low-cost model earns its place. |
| Deployment | Cloud Build + Gemini Flash | Build management, log triage and release-note drafting are frequent, low-judgment tasks, connected to the CI/CD pipeline already standard in EnergIQ's environment. |
The pattern behind the table: steps that need judgment get the deepest and most expensive models, used sparingly. High-volume mechanical steps get the fast, cheap ones. Matching the tool to the task turned out to matter more than the raw capability of any single model.
Where the price actually went
Five things moved it.
The team, before and after
Two roles that were separate line items in the classic model are gone as line items. Testing lives in the pipeline now — non-regression suites generated and run with Gemini Flash, always reviewed by a human before anything regulated ships. DevOps work runs through Cloud Build as part of the same delivery flow. The roles that protect judgment and business knowledge — the functional expert, and at a lighter allocation the architect and the project lead — stayed.
| Role | Initial estimate — classic model | Final estimate — AI-native model |
|---|---|---|
| Scrum Master / Project lead | 50% (0.5 FTE) | 50% (0.5 FTE) — unchanged |
| Technical architect | 50% (0.5 FTE) | 25% (0.25 FTE) |
| Developer(s) | 2 FTE (two developers) | AI-augmented developer — 1 FTE |
| Tester | 1 FTE | — built into AI-generated testing and code review |
| Finance functional consultant | 1 FTE (100%) | 1 FTE (100%) — unchanged, protected |
| Data specialist | 50% (0.5 FTE) | 25% (0.25 FTE) |
| DevOps | 50% (0.5 FTE) | — built into the Cloud Build + Gemini Flash pipeline |
The hours freed up on the architect and data specialist roles didn't disappear — they moved. Less time writing and rewriting code by hand; more of what's left spent on design review, non-regression sign-off and cutover sequencing — the judgment-heavy work AI doesn't do.
On the client side, nothing moved. Both scenarios need a business representative acting as product owner and a project coordinator. AI changes how the delivery-side team is built; the client's own governance roles are untouched.
Why we stopped at fifteen months
A more aggressive timeline was easy to put on a slide. I've watched that slide get approved before and regretted it a few months later, so we argued against it this time, for three reasons.
Migrating module by module means each module proves itself against the live system before the next one starts. That sequence has a minimum length in calendar time that no coding speed compresses.
Every calculation Atlas performs is compliance-sensitive, so non-regression testing against the production baseline — old outputs against new, on real cases — is mandatory and signed off by people. An AI-generated test suite doesn't get to sign off on itself.
And the final cutover has to land outside the platform's peak filing and reporting periods. Those dates come from EnergIQ's business cycle, and no delivery team moves them.
AI compresses engineering time: writing, refactoring and testing code. Validation time, cutover sequencing and a client's regulatory calendar sit outside its reach. A proposal that quietly claims otherwise is borrowing against a risk the client eventually carries.
Part III — What the €1.2M is made of
| Dimension | Second quote — incremental + code assist | Third quote — AI-native, spec-driven |
|---|---|---|
| AI usage | In-IDE code completion only, layered on an unchanged process | A model assigned per pipeline step, from spec reading to deployment |
| Peak team size | ~9 people during the longest phase | ~7 people at peak, smaller core outside peak phases |
| Total effort | ~3,000 person-days | ~2,000 person-days |
| Duration | ~22 months (2-month POC + 20) | ~15 months (6-week POC + phased delivery) |
| Price (rounded, excl. tax) | ~€1.7M | ~€1.2M |
Nearly a third of the effort and a third of the calendar came out between the second and third quotes. AI didn't get 30% better in a few weeks. The second quote used AI as an add-on to an unchanged model; the third used it to redesign the model.
The final proposal carries a 20% risk provision. Early re-pricing had already found modules under-estimated by 35–45%, and we still had limited experience running fully AI-managed projects at this scale — so we priced that uncertainty rather than hoping it away. This is an internal delivery buffer built into AP Advisory's price, not a shared-risk clause with the client.
Twenty percent is what an honest number costs me — for the half of the scope we hadn't fully re-checked, and for a delivery model that, at the time, had no track record.
Around 60% of the third quote still sits with the core technical team — architects and AI-augmented developers writing and reviewing code. The functional expert's share held up as a proportion of the total, which tells you where this model didn't go looking for savings.
What doesn't change
Accountability for what a regulated calculation produces doesn't move. A human still signs off on compliance-sensitive logic before it ships. The same functional expert works on the platform under the new model as under the old. Non-regression testing against production is still the mechanism that catches what an AI reviewer misses.
Across all three quotes, human judgment stayed in exactly the same places. What moved was the amount of mechanical work sitting between a specification and a tested, shippable module — and how honestly the estimate accounted for what nobody had checked yet. I teach a version of this trade-off to executive-MBA students most terms, and it never gets less true: the technology moves faster than the judgment it's supposed to serve.
If you're re-pricing a forfait bid with AI, the short version is this: don't apply a productivity multiplier to your old delivery model and call it finished. Redesign the team, the governance and the cadence around the tools. Assign models by task rather than routing everything through one assistant. Keep the risk provision honest about what you haven't re-checked. That combination is what took this bid from two rejections to a number EnergIQ could negotiate on its merits.
Alin Popovici
Executive advisor, transformation and delivery leader — and a guest lecturer on complex-programme leadership for the Executive MBA at Bucharest Business School (ASE Bucharest, in partnership with CNAM Paris).