How we ship client products in 38 days (not 120) - the operating model behind it

Two years ago, Ailoitte delivered a production-ready SaaS product in 34 days on a fixed-price contract. The client had budgeted for four months. We'd committed to six weeks. We beat it.

That wasn't a fluke. We've now repeated it across 300+ products in 21 countries, with a median of 38 days. This post is an honest breakdown of how the operating model behind that number works, what we built, what failed before it worked, and what the fixed-price commitment actually required of us internally.

This is a process post, not a pitch. If you're a founder evaluating outsourcing partners or building your own delivery model, the details here are what matter.

The problem we were trying to solve
In 2023, we were a competent software studio running time-and-materials contracts. Good engineers, reasonable delivery, open-ended timelines. The structural problem with T&M is that the incentive runs backwards: our revenue went up when projects took longer. We weren't exploiting this, but the structure was still wrong, and we knew it.

When we started integrating AI tooling seriously into our development workflows, the wrongness became impossible to ignore. AI was compressing implementation time by 40–50% on defined tasks. We were either going to bill clients for work that now took half as long (quietly absorbing the efficiency gain as margin), or we were going to restructure the commercial model to reflect what the work actually cost.
We restructured.

• What we actually built: the AI Velocity Pod model

The model is built around small cross-functional units, 3–6 humans, governing a structured layer of specialised AI agents across the full delivery lifecycle.

The human roles shifted completely from a traditional team:
The Pod Lead doesn't write code. They define intent — what the system must do, what constitutes a completed milestone, and what the agent layer is executing against. This role is harder than senior engineering in a traditional team because it requires translating a product vision into specifications precise enough that an agent can execute without ambiguity. Loose specs produce loose output.

The Review Engineer doesn't review every line. They review diffs at defined milestones against documented acceptance criteria. Gate-keeping, not implementation.

The QA Orchestrator doesn't write test cases. They configure and interpret a continuous agentic QA pipeline that runs at the commit level, not at the sprint end.

The Domain Expert carries the institutional knowledge that AI cannot infer — business logic, regulatory constraints, the edge cases that only emerge from understanding why the system exists, not just what it does.
The agent layer handles:

Code generation, refactoring, test suite generation, documentation, and first-pass code review. Specialised agents with defined scopes, not a generalist model, are asked to "build the feature."

The fixed-price commitment: what it requires internally
This is the part most posts skip.
First: the scope governance system.

Fixed price without a precise scope is a disaster waiting to happen. Every engagement starts with a discovery sprint that produces a single document: a line-item scope agreement specifying exactly what ships, what doesn't, and what triggers a formal change order. This document is the contract's foundation. Nothing moves to development without it.

Writing this document well,, precisely enough that there's no ambiguity about what's included, is harder than the development work that follows. It requires the Pod Lead to think through the entire product before a line of code is written. That discipline is uncomfortable and time-consuming. It's also the thing that makes the 38-day number repeatable.
Second: the financial model.

Fixed-price requires a completely different P&L logic. Under T&M, efficiency gains flow to margin or get billed away; there's no structural incentive to get faster. Under a fixed price, your margin is (fixed price) minus (cost to deliver). Every hour of internal efficiency gained through AI tooling goes directly to margin. We profit from shipping faster. That alignment is what makes the model honest and what drives genuine investment in workflow improvement.
Third: holding the line on hourly fallbacks.

The internal pressure to offer "flexible hourly options" for difficult sales conversations is constant. Every time a client pushed back on fixed price, someone internally would suggest we offer a T&M alternative. We didn't, because every exception to fixed price requires an exception to scope governance, which breaks the entire model. Maintaining that discipline when it costs you deals in the short term is what builds the model's integrity over time.

• What failed before it worked

Scope documents that weren't precise enough. The first several projects using this model had scope agreements that we thought were detailed but turned out to have ambiguities that only surfaced mid-sprint. Each gap became a negotiation under deadline pressure. We built a scope review checklist, a second-pass audit of the scope document, specifically looking for ambiguous inclusions, undefined edge cases, and unstated assumptions. That checklist is now a mandatory step in every discovery sprint.

QA infrastructure is deployed after the agents. Early on, we stood up the agentic development pipeline before the agentic QA pipeline. The result: we shipped faster but caught defects later. AI-generated code fails at the edges in patterns that traditional QA doesn't catch well, edge case blindness, context collapse across module boundaries, hallucinated library methods that compile but break at runtime. We rebuilt the sequencing: QA infrastructure first, always. Development agents second.

Scope agreements without a formal change order process. A scope agreement without a documented change order process is still a T&M contract with extra steps. Clients would request additions mid-sprint, small things, reasonable things, and without a formal process, those additions would get absorbed informally, eroding the fixed-price model from within. We introduced a written change order protocol: any addition to scope is a new engagement with its own fixed price and timeline. This felt adversarial at first. It isn't, it's clarity, and clients who understand the model appreciate it.

• The numbers after two years

Median delivery: 38 days (comparable scope, across 300+ products)
Change order rate: under 15%, meaning scope governance is working upstream
Cost to clients: 70–85% lower than traditional agency engagements on comparable scope
Countries shipped to: 21

The 38-day figure gets the attention. The one that represents actual model health is the change order rate. Low change orders mean the discovery sprint is catching everything that needs to be defined before development starts. That's the discipline that makes the rest of the numbers possible.

For founders evaluating outsourcing vs. building in-house
The build-vs-buy question in 2026 has changed. The traditional trade-off was speed (outsource) versus control (in-house). AI-native, fixed-price outsourcing adds a third dimension: accountability structure.
Under T&M outsourcing, you monitor the burn rate. Under fixed-price outsourcing with scope governance, you monitor milestones against acceptance criteria. Those are fundamentally different relationships. The first requires you to trust the vendor's time tracking. The second requires you to trust the vendor's scope discipline, which you can verify by reading the scope agreement before you sign.
The questions to ask any outsourcing partner:

Can I see the scope agreement from a comparable recent project?
What's your formal change order process?
How is your QA pipeline designed for AI-generated code specifically?
What's your median delivery time on a comparable scope, measured across the last twelve months, not your fastest project?

A vendor who answers all of these with specificity is operating a real model. A vendor who pivots to portfolio and testimonials is selling.

• One open question

We've refined the model across 300+ engagements, but one challenge remains active: clients whose internal procurement processes are structured around hourly billing.
The fixed-price model is the right commercial structure for AI-native delivery. But "right" doesn't mean "easy to buy" in organisations where every vendor evaluation form asks for an hourly rate. We've gotten better at navigating this — but curious whether others building product studios or service businesses have found ways to accelerate the procurement conversation when the buyer's system is built for T&M.
How do you handle buyers whose procurement systems are structured for hourly billing when you're operating a fundamentally different model?

If the operating model here is relevant to what you're building:

AI Velocity Pod model in detail →
Documented delivery outcomes →