The Forge Method: How Two People Ship a New AI Product Every Week

We once spent the better part of a month rebuilding something we had already built.

Two people, no product department, no standup to catch it — so a tool got made a second time because the person making it didn't know the first one existed. By the time we noticed, the cost wasn't just the wasted month. It was the lesson underneath it: for a small team, the most expensive bug isn't in the code. It's in the memory. You don't lose weeks to hard problems. You lose them re-solving easy ones you forgot you'd already finished.

Almost everything about how we build now is a reaction to that month. People hear "a new product roughly every week, two founders" and assume corner-cutting. It's closer to the opposite. We got strict — in a specific and slightly unusual way — about never doing the same work twice, and we put a paper trail around the AI doing the building so it couldn't quietly repeat that mistake at machine speed.

## The moat is a search box, not a factory

"The factory is the moat" is the tidy version, and it's only half true. Any single product is copyable — a determined competitor could clone the UI in a fortnight. What's genuinely hard to copy is that we can build the twelfth product about as cheaply as the third, and that only holds if we can reliably find what already exists before we build the next thing.

So the real asset isn't a factory in the abstract. It's a live register — a searchable index of every product, every reusable block, every deployed service across both our build lanes — that we are required to query before writing a line of new code. The rule is blunt: search first, and any hit means you wire into what's there, you do not build a second one beside it. It sounds like bureaucracy. It's the single control that turns "two people with AI" from a thing that forgets itself into a studio that compounds. That expensive month bought the rule, and the rule has paid for itself many times over.

Reuse-first isn't a virtue we chose for its own sake. At two people, it's the only way the maths works. Eight people can afford to rebuild plumbing; two cannot, and pretending otherwise is how two-person studios stay stuck shipping one product at a time forever.

## Shared rails: the boring decisions that buy the speed

The plumbing we refuse to duplicate is deliberately, almost aggressively boring.

Every product bills through one payment account — the whole family on one rail, not a fresh integration per app. Conventional advice says isolate billing per product. We do the opposite on purpose: two people cannot reconcile a dozen payment accounts or keep a dozen webhook-idempotency implementations honest, and getting "never double-charge the customer" exactly right once beats getting it roughly right twelve times.

Model access runs through one shared AI gateway instead of each product carrying its own provider keys. That isn't tidiness for its own sake — per-product keys are how small teams die by a thousand rotations. One gateway means we swap a model, cap a runaway cost, or kill a leaked key once, centrally, instead of editing a dozen codebases and hoping we caught them all. When a provider drops prices or a stronger model lands, every product inherits it the same afternoon.

The reuse this buys is concrete, not theoretical. InvoiceForge and ProposalForge sit on the same billing rail and the same gateway; the only genuinely product-specific code is the part that turns a filled-in form into an invoice versus a proposal. Everything underneath is assembly, not invention — which is exactly why a new one can go from idea to deployed in the time most teams spend scoping the payment integration alone.

## Where the honesty has to go: "fast" is not "finished"

Two things we hold ourselves to, because the real failure mode of this method is believing your own launch cadence.

We're consolidating those shared pieces into a single platform layer we call Pharoah Core. Said plainly, once: Core is being assembled, not finished. The reuse is real today, but it lives across a shared payment account, a shared gateway, a common deploy path and a shared review pipeline — several rails that already work, not one backend that already does everything for every product. Each product still deploys as its own service while we bring that layer together. "Assembling it" is the honest tense. "Done" would be a claim the register itself would catch.

And shipping something in a week is not the same as it being finished. The family has grown past a dozen tools, and they are not uniformly done. A couple are feature-complete, with a live checkout and a real price on them; several others are earlier — thinner, still being filled in, honestly nearer prototype than product. The rails make the first version cheap. They do not make the tenth iteration free. Speed gets you to a real product fast; it does not excuse the unglamorous work of making it good, and treating "shipped" and "finished" as the same word is the quiet lie in every "we launch weekly" claim.

## Governance you spend where a mistake becomes a harm

Here's the part most AI-built products skip. We don't let the AI grade its own work — and we don't spend our review budget evenly. We spend it by blast radius.

The pipeline splits into three roles that never collapse into one: a planning model breaks the task down, a build model executes against that plan, and a separate reviewer model checks the diff. The reviewer is never the builder — that's a rule, not a preference — because a model reviewing its own output tends to agree with itself, and the entire value of a review is that it can disagree.

But the sharper idea is that not all changes carry the same risk, so not all changes earn the same scrutiny. A copy tweak or a config change gets a light self-check and moves on. Ordinary feature work gets the independent reviewer. Anything that can actually hurt someone — payments, authentication, a child-facing safety path, a database migration — never gets built by the cheapest model at all; it's built by a stronger one and then checked twice, independently. You don't audit a typo the way you audit a wire transfer. Reviewing everything to the same depth isn't rigour, it's just slow — and slow is the one thing a two-person studio can't afford to waste on low stakes.

Nothing goes live because the build model said it was fine. It goes live because a separate, governed check said so — and the depth of that check is proportional to what breaks if it's wrong.

## What it costs us

This isn't free, and pretending it were would be its own kind of dishonesty.

Reuse-first bends every new idea, slightly, toward what the rails already support. Sometimes the ideal version of a feature isn't the one that reuses existing infrastructure — and sometimes we ship the second-best version anyway, because a two-person team that indulges every perfect exception ships nothing. That's a real trade, not a rounding error.

There's a sameness risk, too. One payment rail, one gateway, one pipeline — and products can start to feel like variations on a theme rather than distinct tools. We manage it by keeping the product-specific logic — the part that actually solves the customer's problem — deliberately separate from the shared rails, and by being willing to admit when an idea needs its own shape rather than a family template. The register tells us what we can reuse. It doesn't get to tell us what to build.

## The point

Speed without governance is how AI-built products end up brittle and interchangeable. Governance without shared rails is how small studios stay small, one hand-built product at a time. The method is our answer to both at once: build fast because the rails already exist and the register stops us rebuilding them, ship safely because no model reviews its own homework and the risky work never touches the cheap model.

It started with a month we'd like to have back. If you're running a small studio and want to compare notes on the register discipline or the model-routing pipeline — what's worked, and what still bites — get in touch.