What Comes After the Vibe-Coded MVP

The job

“It works. People are using it. And I am the only thing between it and falling over.”

A prototype’s job is to find out whether anyone wants the thing. While that is the job, it is allowed to keep its credentials in a .env, to have one deploy path that only works from your laptop, and to carry a backlog that lives in your head. Shipping it that way was the right call — it is why it has users.

The moment it has users, those three stop being shortcuts. What the product needs next is not more code. It needs a deploy that any change can go through without you in the loop; an environment close enough to production to be worth testing on; secrets somewhere other than the repository; and someone still building the next feature while all of that gets sorted.

That is an engineering function, and the usual options are to be it yourself at night, hire a senior engineer you cannot afford yet, or rent a fractional CTO for a few hours a week. Forge is a fourth option, and it is two halves: deployment you install, and a product team that works the way a team works — in your repository, through pull requests, with a review step before anything lands.

The deployment half

Forge deploys with sc, Simple Container — the same open-source core it uses to deploy itself.

• One declarative stack definition per service. What it is, where it runs, what it needs. No hand-written pipeline per service.
• Your cloud account. It provisions on Amazon, Google, Yandex Cloud, Kubernetes, or servers you own. The account, the data and the bill stay yours.
• Secrets stop living in the repository. They sit in an encrypted registry and are decrypted at deploy time, so nothing readable is committed and nobody has to pass a .env around.
• An environment per change. A full copy of the service matrix can be stood up on its own subdomain, tested, and destroyed — see Isolated Stacks .
• Auditable by someone other than us. MIT-licensed, OpenSSF Best Practices Gold with every criterion met, Scorecard 10/10. You can read the thing that deploys your product.

The product team half

The chain most teams recognise, with a supervisor between every step:

What makes this different from pointing a coding assistant at a ticket is the validator between transitions. Each handoff is read by a management agent that decides whether the next role should receive it — and when the answer is no, the work goes back with specific instructions rather than flowing downstream to become somebody else’s problem.

The second difference is that everything is written down. Each role’s output is a commit on the run’s branch, so the reasoning, the rejected attempts and the verdicts are all there when you read the pull request. You are not reviewing a black box’s output; you can see how it got there, and you can take over mid-run by committing a corrected handoff yourself.

The third is that a person merges. Auto-merge exists, it is opt-in, and it is bounded by an autonomy budget — but the default is that you press the button.

Where to start

Two things, in this order, and neither of them is a rewrite:

1. One service, one environment. Describe what you already run and deploy it through sc once. From then on the deploy is a command rather than an afternoon, and the environment per change comes with it.
2. One well-specified ticket. Point the delivery chain at it and read the pull request it opens — the branch, the handoff commits, the verdicts that sent work back. That is the honest measure of whether this fits how you build.

Vague tickets produce vague pull requests; the PM step surfaces the ambiguity rather than inventing an answer, which is correct but does mean it comes back to you first.

Evidence

The strongest evidence we have is that this is how Forge is built. An autonomous driver reads our roadmap, picks the next actionable item, dispatches this chain against it, and the resulting pull request is merged into the platform’s own repositories. The fleet of services behind the platform — control plane, AI gateway, runtime, storage, notifications — deploys with the same sc core: on Amazon, and on Yandex Cloud where the work has to stay in Russia.

Those repositories are private, so we will not pretend you can go and audit them. What we can do is walk you through real runs: the branch, the commits, the verdicts that sent work back, and the ones that escalated to a human. It is the same code you would be running, and we would rather show you that than a benchmark.

Under the hood

• From Ticket to Reviewed Pull Request — the delivery chain in detail
• Multi-Agent Pipeline — the roles and the validator between them
• Isolated Stacks — the throwaway environment every change proves itself in
• Git-Backed Audit — why the record is commits rather than a dashboard
• Secrets & Egress — where credentials live and what an agent can reach
• Observability — per-turn logs and metrics for every run you dispatch
• Actionable Notifications — where a run talks to you when it needs a decision