AI collapsed the fixed cost of running a software company, not just coding speed. Here's what a two person team can now ship that used to take ten to build.
A client once asked me why a feature they wanted would take three months, and I gave him an honest answer that had almost nothing to do with the feature. The feature was maybe two weeks. The other ten went to the admin dashboard, the docs, the migration scripts, the support inbox, the onboarding emails, the billing edge cases, the error monitoring, and the second language nobody remembered to plan for. That's the part clients never see and always underprice: the software isn't the product, the company around the software is.
That wrapper is what got cheap. Not "coding is faster" — I mean the fixed cost of standing up a whole software company dropped by an order of magnitude, and most people are still pricing their ambitions off the old math. The interesting question isn't whether AI writes your CRUD faster. It's which formerly-impossible things a two-person team should now walk straight at.
I've spent six-plus years shipping production Flutter and Firebase apps, most of them on teams small enough to count on one hand. So this isn't a think-piece from the sidelines — it's what actually changed in how I scope work, hire, and decide what's worth building, and where the AI-leverage hype badly overshoots reality.
Every product has two kinds of cost. There's the marginal cost of the next feature, and there's the fixed cost of being a company that ships software and keeps it alive. Small teams have always been fine on the first one. We die on the second.
The fixed costs of running a software company looked like this:
None of that scales down. A ten-person team amortizes it across ten people. A two-person team pays the same absolute cost with a fifth of the bodies, which is why so many good two-person products just... stall. Not because the founders ran out of ideas. Because they ran out of themselves keeping the wrapper alive.
So certain categories were simply off the table for a small team. Anything with heavy support load. Anything needing serious docs. Anything where the operational surface was large relative to the core value. We'd look at it, do the headcount math in our heads, and quietly not start. The idea was never the blocker. The fixed cost of the company around the idea was.
Let me be precise, because the hype merchants are not. The collapse is real but uneven, and the difference between real and imagined leverage is exactly where small teams win or waste a year.
Collapsed hard — the work AI genuinely absorbed:
Barely moved — the work that's still expensive:
The pattern underneath is consistent. AI collapsed the cost of work that is high-volume, low-stakes-per-item, and verifiable by a human in seconds. It did not collapse the cost of judgment, of being right when being wrong is expensive, or of anything the model can't check against reality. If you remember one heuristic from this post, make it that one: AI is cheap where a human can verify the output in seconds and expensive everywhere verification is slow, subjective, or impossible.
On a recent project we built an internal ops console — user lookup, refund flow, feature-flag toggles, audit log — in about two days. Two years ago I'd have budgeted two weeks and probably cut half the features to fit. The console wasn't clever. It was just tolerable to build now, and that tolerability is the whole story.
Everyone talks about AI writing features. In practice, the first thing it quietly ate on my teams was the unglamorous wrapper — and that's exactly where the leverage was, because that's where small teams were bleeding.
Support is the clearest case. The bottleneck was never typing the reply. It was reading a confused message, figuring out which of forty screens the user meant, checking their account state, and reconstructing what went wrong. A model that can read the ticket, pull the user's recent events, and hand me a draft with the likely cause turns a fifteen-minute context-reload into a two-minute confirm-and-send.
Here's roughly the shape of the triage step we run before a human ever sees a ticket:
async function triageTicket(ticket: Ticket): Promise<TriageResult> { const user = await getUserContext(ticket.email); // plan, recent errors, last events const similar = await searchResolvedTickets(ticket.body); // past resolutions, deduped const result = await model.classify({ ticket: ticket.body, userContext: user, priorResolutions: similar, // return a category, a likely root cause, and a DRAFT reply — never auto-send schema: TriageSchema, }); return { category: result.category, suspectedCause: result.suspectedCause, draftReply: result.draftReply, confidence: result.confidence, // low confidence => straight to a human, no draft shown };}The rule that matters is in the comment: it drafts, a human sends. The moment you let it auto-resolve, you've traded a support cost for a trust cost, and trust is more expensive. I gate on the confidence field deliberately — anything below a threshold skips the draft entirely and goes to a person cold, because a confidently-wrong draft is worse than no draft. It biases the human toward accepting a bad answer.
Docs are similar. I stopped treating documentation as a separate project and started generating a first pass from the code and changelog, then editing for the 20% the model can't know — the why, the sharp edges, the "don't do this, we learned the hard way." The draft is 80% of the volume and 20% of the value, which is exactly the split you want to hand a machine. The trap is shipping the draft unedited: auto-generated docs that describe what the code does without the why read plausible and help no one, which is arguably worse than no docs at all.
Ops is the quiet one. Runbooks written from incident history. Log-noise summarized into "here are the three things that actually changed since the last deploy." Alert rules drafted from past incidents instead of from guesswork. None of it is glamorous. All of it used to require a person we couldn't afford to hire.
When capacity stops being the bottleneck, whatever was the second bottleneck becomes the first. For most small teams, that's taste and direction.
I feel this daily now. I can generate five plausible implementations of a feature in the time it used to take to write one. That doesn't make me five times better. It makes the choosing the hard part — which of these is actually right for our data model, our latency budget, our future selves. The model is happy to build all five. It has no opinion on which one we should live with for three years.
This flips how I spend my hours. Less time typing, far more time on the questions that don't have a generated answer:
A junior engineer with AI ships more code. A senior engineer with AI ships more decisions. The gap between those two just got wider, not narrower, because the code was never the scarce part for the senior — the judgment was, and now it's the only part that's scarce. AI is a leverage multiplier, and leverage multiplies whatever you point it at, including bad direction. Point it at the wrong problem and it builds you the wrong thing faster than ever.
Here's the failure mode nobody warns you about, and I walked straight into it. When shipping gets cheap, you ship too much. Every feature you generate in an afternoon is a feature you own forever.
Maintenance cost didn't fall the way build cost did. A model can write a new integration in an hour. It cannot feel the weight of the eleven integrations you already have, each one a support surface, a security surface, a thing that breaks when a third party changes an endpoint. Generated code is not free code. It's a liability you produced faster — and unread generated code is a liability you don't even understand yet.
On one product we added features for a full quarter at a pace that felt incredible. Then the bug reports arrived — not from bad code, but from surface area. Too many half-loved features, each with its own edge cases, none of them the thing users actually came for. We spent the next quarter deleting. That was the real lesson: the constraint moved from "can we build it" to "can we stand to keep it alive."
My rules now, written on the wall:
If two people can do what took ten, the obvious conclusion is "hire fewer people." That's half right and mostly wrong.
The right conclusion is: hire for the things that didn't collapse. I don't need more hands for volume anymore. I need judgment, taste, ownership, and the ability to be right when the model is confidently wrong. That's a different hiring bar, and it's a higher one.
Here's how my thinking shifted, side by side:
| Old hire | New hire |
| --- | --- |
| Fills a capacity gap | Fills a judgment gap |
| "Can they build this?" | "Can they decide what's worth building?" |
| Ramps by learning the codebase | Ramps by learning the domain and the users |
| Value scales with hours | Value scales with the quality of their calls |
| Owns a module | Owns an outcome |
The one thing I've stopped compromising on is what I'd call model literacy — knowing when to trust the output and, more importantly, when not to. Someone who ships AI-generated code without reading it is negative leverage. They're not faster; they're a debt-generator with good velocity metrics. I'd rather have one person who reads every line the model writes than three who don't, because the three-who-don't quietly fill the codebase with things nobody can maintain.
I'm also hiring later than I used to. When a problem shows up, my first question is no longer "who do we hire for this." It's "is this a headcount problem or a tooling problem." Most of the time now, it's tooling. Reaching for a hire is the expensive, slow, hard-to-reverse move — I save it for the judgment gaps that no tool fills.
This is the question that keeps founders up, and it should. If your competitor has the same models you do, and the models keep getting better for everyone at once, where's the defensibility?
Not in the model. The model is a utility now, like electricity — a real advantage to have, no advantage over anyone who also has it. The moats moved to the places AI can't reach:
Notice that a two-person team can hold every one of those. None of them require scale. Several of them are easier at small scale — a tiny team iterating on real feedback is a genuine edge against a company that has to route decisions through five layers of approval. The collapse of fixed costs didn't just let us build more. It made the surviving moats ones that small teams can actually own.
Concretely, here's what moved from "no" to "yes" for a team my size — the specific product shapes worth hunting for when fixed costs collapse.
The connective thread: every one of these was blocked by fixed cost, not by the core idea. The ideas were always fine. We just couldn't afford the wrapper. Now we can, and the strategic move is to deliberately hunt for the things that used to be uneconomic — because that's where the competition is thinnest, since everyone else is still doing the old headcount math and quietly not starting.