Build SaaS with AI: what the 3-10x speedup claims leave out

Read enough guides on building SaaS with AI and one number starts repeating itself: three to ten times faster. Sometimes it is attributed to a survey, usually to nobody. Several of the pages that quote it end in affiliate links to the tools that supposedly deliver it.

I build SaaS with AI coding agents every day. They are the biggest change to how I work in a decade and I would not go back. The multiplier is still wrong, and it is wrong in a way that costs founders money, because it gets used to set budgets and deadlines for exactly the parts of a build where AI helps least.

This is what the multiplier actually measures, what the controlled studies found, and where the time goes on a real SaaS build when an agent is writing most of the code.

Where three to ten times comes from

The multiplier is real for one specific thing: time to the first working version of a greenfield feature, measured by the person who wrote the prompt. Ask an agent for a CRUD screen with a form, validation, a table and a migration, and it produces in four minutes what used to take an afternoon. That is comfortably ten times faster.

Then three things happen that the demo never shows. Somebody has to read it. It has to fit the codebase it is going into, not the one the model imagined. And it has to be right in the cases nobody prompted for: the second tenant, the retried webhook, the user whose role changed halfway through a session. The multiplier measures the first step and stops the clock.

What the controlled studies measured

There are only a handful of randomised trials, and they are the only kind of evidence that controls for developers feeling faster. They point somewhere less exciting than the marketing.

faster on one self-contained taskGitHub Copilot trial, 2023: write an HTTP server in JavaScript from scratch

55.8%

faster on an enterprise taskGoogle randomised trial with around 100 of its own engineers, 2024

~21%

slower, in codebases they knew wellMETR trial, 2025: 16 experienced open-source maintainers, 246 real issues

19%

drop in delivery stabilityDORA 2024 estimate for every 25% increase in AI adoption

7.2%

The METR result is the one worth sitting with. Before starting, the developers predicted AI would make them 24% faster. After finishing, they estimated it had made them 20% faster. Measured against tasks done without it, the work took 19% longer. The time went into prompting, waiting, reading output and fixing code that was nearly right.

Line the four up and the pattern is clear. The biggest gain is on a small task, starting from nothing, with an obvious definition of done. The smallest gain, or a loss, is on a mature codebase full of context the model does not have. A SaaS platform starts as the first kind and turns into the second somewhere around month three.

The arithmetic a multiplier skips

Typing code was never most of the work. On the SaaS builds I scope, writing code is somewhere between a third and a half of the hours. The rest is deciding what to build, reading existing code, reviewing, testing, deploying, and talking to the people who will use the thing. Make the coding part infinitely fast and the whole build gets, at best, about twice as fast. That is Amdahl's law, and no tool vendor has repealed it.

So the useful question is not how fast AI writes code. It is how much each part of a SaaS build shrinks once the review is counted. Here is my estimate phase by phase, against the same breakdown I use for what a SaaS MVP actually costs.

One and a half times is a very good result. It takes a third off the bill for a production platform, and on a seven week lean MVP it saves two to three weeks. It is just not three to ten, and planning for ten means discovering in week six that the plan was fiction.

Where AI genuinely earns its keep

The phases that shrink most in that chart have something in common. The code is low risk, the patterns are well worn, and checking the result is quicker than producing it.

• Admin and back office. Tables, filters, forms and CRUD over models that already exist. You review it by clicking through it. Often the single biggest saving in the build.
• Front end from a design system. Give an agent a component library and one finished screen and it produces consistent UI quickly. Review is visual, which is fast.
• Integrations with good documentation. Email providers, well known APIs, SDK wiring. The model has seen thousands of examples and the vendor's docs fill in the rest.
• Reading unfamiliar code. Asking an agent to explain a module or trace where a value comes from is the most underrated use there is, because reading is the part the studies say dominates.
• Mechanical refactors with tests already in place. A rename across two hundred files, verified by a suite that existed before the change, is exactly what agents are for.

Where review eats the gain

Every AI-written bug I have had to fix on a SaaS codebase has the same shape. The code was plausible. It compiled, it passed the tests generated alongside it, and it handled the case described in the prompt. It failed on the case that is only obvious if you know what the system is for.

That bites hardest on the boundaries, because they are the places where nearly right is a breach rather than a bug: tenancy, authorisation, money and deletion. A payment webhook is the cleanest example. Ask for a Stripe webhook that marks an invoice paid and you will very often get something like this:

// Plausible, and wrong in three ways.
Route::post('/webhooks/stripe', function (Request $request) {
    $event = $request->all();

    if ($event['type'] === 'invoice.paid') {
        $invoice = Invoice::where('stripe_id', $event['data']['object']['id'])->first();
        $invoice->update(['status' => 'paid']);
        Mail::to($invoice->account->owner)->send(new PaymentReceived($invoice));
    }

    return response()->noContent();
});

It works in the demo. It never verifies the signature, so anybody who finds the URL can mark invoices paid. It is not idempotent, and Stripe retries deliveries, so customers get the receipt more than once. And it trusts the order events arrive in, which Stripe explicitly does not guarantee. The version that survives production:

Route::post('/webhooks/stripe', function (Request $request) {
    try {
        $event = Webhook::constructEvent(
            $request->getContent(),
            $request->header('Stripe-Signature'),
            config('services.stripe.webhook_secret'),
        );
    } catch (SignatureVerificationException) {
        abort(400);
    }

    // Stripe retries. The event id is a primary key, so a repeat inserts nothing.
    if (ProcessedEvent::insertOrIgnore(['id' => $event->id]) === 0) {
        return response()->noContent();
    }

    // The job re-reads the invoice from Stripe instead of trusting this payload,
    // so a late invoice.payment_failed cannot overwrite a newer success.
    ProcessStripeEvent::dispatch($event->id, $event->type);

    return response()->noContent();
});

None of that is exotic. It is all in Stripe's documentation. But the reviewer has to know to look for it, and reading four hundred lines of plausible code for the three that matter is slower than writing those three yourself. That is where the multiplier goes.

The costs that arrive after launch

A build estimate stops at launch. The cost of AI-written code mostly does not.

Nobody wrote it. Hand-written code has an author who carries a model of it in their head. Generated code has a reviewer who skimmed it once. Every later change starts with reading, and reading is the part AI accelerated least. There is more of it. When code is cheap to produce, codebases grow faster than they would have, and GitClear's analysis of 2024 commit data found duplicated blocks rising sharply as assistants spread. Every duplicate is a place a fix has to be made twice. The bill is ongoing. Agentic coding on a large codebase burns tokens on every task, and the habits that keep that sane are the same ones in not every call needs the expensive model.

None of this argues against using AI. It argues for the same discipline that has always decided whether a codebase survives year two: boring structure, one way of doing each thing, and rules enforced by tooling rather than memory. The agent will copy whatever pattern it finds most of. Make sure that is the right one.

How I actually use it on a SaaS build

1. 1Architecture first, by hand. The decisions that cost most to reverse get made before the agent writes a line, because an agent will happily pick a shape for you and repeat it in four hundred files.
2. 2A harness, not a chat window. Project rules, lint, type checks and tests the agent must pass before it reports done. Harness engineering is what turns generated code into reviewable code.
3. 3Small diffs. A change I cannot review properly in fifteen minutes is a change I have not really reviewed. Splitting the task is cheaper than trusting it.
4. 4Humans own the boundaries. Tenancy, authorisation, billing state and deletion are written or line-reviewed by an engineer who knows why they are shaped that way.
5. 5Measure outcomes, not feelings. Cycle time from ticket to production and defects that reach customers, not lines generated or how fast it felt. The METR developers felt 20% faster.

So what should you budget?

With a senior engineer driving the agents and owning the boundaries, against the ranges in the MVP cost breakdown:

• A clickable prototype: two to three weeks becomes a few days. This is where three to ten times is honest, because a demo is exactly the small, greenfield, low-stakes task the multiplier was measured on.
• A lean MVP, one workflow with real users and real data: seven to nine weeks becomes roughly five to six.
• A production platform, multi-tenant with self-serve billing, admin and reporting: twelve to twenty weeks becomes roughly eight to fourteen.

If someone quotes you a production SaaS platform in two weeks because AI, ask what they are leaving out. The answer is usually tenancy, billing edge cases and tests, which is to say the parts that decide whether the product can safely take money.

AI made writing code cheap. It did not make knowing which code is wrong any cheaper, and on a SaaS platform that is most of the job.

If you want a SaaS platform built with AI doing the heavy lifting and an engineer owning the boundaries, or you already have an AI-generated codebase and want someone to find what it gets wrong before your customers do, tell me what you are building. I will come back with a scope, an honest timeline and a fixed price. See how a SaaS build is scoped and priced.