How Paradigm builds SaaS in 2026

Most software does not move slowly because the people are slow. It moves slowly because it works, and hundreds or thousands of people have arranged their day around it working exactly the way it does now. Change the schema and you break an integration someone built two years ago. Change the login flow and you generate a support queue. Change anything and you owe a migration, a comms plan, a rollback, and a meeting about the meeting. That drag is not incompetence. It is the tax you pay for having users who depend on you.

Paradigm does not pay that tax yet. That is the whole edge, and I want to be precise about what it is and is not, because the dishonest version of this post writes itself and I would rather you trusted the boring true one.

The honest thesis

The edge is freedom from backward compatibility, plus a build process where a lot of the work is done by AI agents under close supervision. Those two things compound. When there is no installed base to protect, you can rewrite the access model on a Tuesday. When most of the mechanical build is delegated to agents and gated by automated checks, one person can hold more surface area than a small team used to. Put them together and the loop from “that is a good idea” to “that is shipped and reviewed” is measured in days, not planning cycles.

Here is the part the marketing version leaves out. “Near zero legacy obligations” and “near zero customers” are the same sentence read two ways. The freedom to change anything is real, and so is the fact that we do not yet have a large base of paying users stress-testing every corner. I am not going to sell you the first half and hide the second. The advantage is architectural, not a claim that nobody else can ship fast. Amazon deploys to production roughly every eleven seconds; the idea that big companies cannot ship is a caricature that any engineer will see through. What big deployments carry, and we do not, is the migration-and-change-management weight of an install base. That is the specific thing we are unencumbered by. Not speed in the abstract. Drag.

The stack that makes it real

None of this works on vibes. It works because there is an actual assembly line, and each station has a job.

• A planner (Opus) takes a fuzzy goal and produces a real plan: a dependency graph of chunks, each with an executor tier, a definition of done, explicit edges, and named review points. Not a wish list. A build order.
• A decomposition pass splits a feature too big for one sitting into independently verifiable chunks, each with a mechanical acceptance check so “done” is a thing a machine can confirm, not a feeling.
• An executor (Fable) works the chunk graph top to bottom, one fresh context per chunk, with a human review between chunks instead of one giant unreviewable diff at the end.
• A council of agents gets pointed at anything genuinely contested. Six personas argue, on the record, and are required to actually rebut each other rather than nod in parallel. A contrarian hunts the failure mode nobody is saying out loud, a researcher pulls current outside data, a logician checks whether the conclusion actually follows, and a synthesizer writes the verdict.
• A quality gate runs before anything is called finished: a multi-lens review across security, functionality, modularity, and usability, with the mechanical parts (dependency CVEs, secret scans, accessibility, end-to-end smoke) fanned out to cheaper agents in parallel and the judgment parts kept expensive.
• A decisions log records every meaningful design call with its reasoning and tradeoffs, and when a decision gets reversed later, the original entry stays and the reversal is appended. You can read why the current shape exists, including the wrong turns.

The important word there is supervision. Agents do not get to merge to production because they feel confident. They produce work; the gates and the human decide whether it survives.

What that looks like in practice

A recent example, sanitized. The portal that ties our apps together went from an empty repo to a live, multi-tenant, single-sign-on product over a few weeks: fifteen pull requests merged in about twenty days in one repo, each one a scoped chunk with its own tests, stacked so that later work builds on reviewed foundations instead of a swamp. The tenant-isolation logic, the part that decides which customer can see which app, is a single pure function with twenty-seven passing tests, because that is exactly the code you do not want clever.

Before I wrote this post, I ran the core claim through the council in its adversarial mode. My first draft led with “we iterate ten times faster than big SaaS.” The council killed it inside two rounds. The researcher produced actual numbers: controlled studies of AI-assisted development cluster around modest multipliers on greenfield work and can go negative on mature codebases, and there is no credible measurement anywhere that supports a clean 10x. The logician pointed out that “10x” with no baseline, no interval, and no named competitor is not a claim you can be wrong about, which means it is not a claim at all. So it is gone. What you are reading is the version that survived its own review, which is the point of having one.

The tradeoffs, stated plainly

If this only had upside it would be a pitch, not a description.

Small base cuts both ways. No legacy drag also means limited real-world load. Some classes of bug only show up when strangers who did not build the thing start using it in ways you did not imagine. We have fewer of those strangers than I want.

The gate catches things, and it catches some of them late. Our last full quality gate came back with a blunt no-go and a punch list: a couple of genuine problems that reached a running environment before the review caught them, both small, both fixed in the queue. I could hide that. I am telling you instead, because a process whose value is that it surfaces its own escapes, with a paper trail, only earns your trust if I show you it doing that on my own work. A gate that only ever reports good news is a smoke detector with the battery out.

One founder plus agents is a real operating model and a real single point of failure at once. I run this. The agent stack multiplies what I can do; it does not clone my judgment, and the studies are clear that solo operations carry higher risk than teams. I would rather you knew that going in than discovered it later. The mitigation is that the decisions log, the gates, and the plans are written down precisely so the process does not live only in my head.

The stack is a head start, not a moat. Anyone can install the same tools by next week. What does not copy in a weekend is the accumulated corpus: the specific gate rules, the decision history, the patterns that encode what bit us last time. That is a lead measured in weeks, not a wall. I intend to keep widening it, but I am not going to pretend it is unbreachable.

Where it goes

The near-term work is turning the velocity from a story into a number: cycle time from spec to merged, defect-escape rate over releases, gate pass rate. Those are the metrics that convert “we ship fast” into “we ship fast and it holds,” which is the only version worth anything to a customer. The medium-term bet is that the assembly line itself, the part that got sharper every week we used it, becomes as much the product as anything it builds.

If that sounds less triumphant than the usual founder post, good. The thesis is simple and I will stand behind exactly this much of it: we are unencumbered by the obligations that slow mature software down, we build with a supervised multi-agent process that is fast and leaves a paper trail, and we are early enough that the honest tradeoffs are still visible. When they stop being visible, it will be because there are enough of you using this to bury them, and that is the good problem.

That is how Paradigm builds in 2026. Ideas are cheap, the build is fast, and the review is real. The rest is just doing it in public.