Every coding agent starts at a ticket.

Devin, Codex, Copilot, Factory — hand any of them a well-formed unit of work and they will hand you back a pull request. That unit of work is written by a product manager, refined by an architect, and filed by a team.

A founder building alone employs none of those people.

The other door is a hosted builder. It will show you something working in ninety seconds, on a substrate you don't own.

So the choice today is a tool that assumes a company you don't have, or a tool that keeps the thing you're building.

Ironworks exists and runs today against real repositories: a product interview that writes the requirements, an architecture interview that writes the technical design, a tech lead that decomposes it into milestones and issues, and a coordinator that drains that queue every five minutes with a team of agents.

Getting to the first tick takes about an hour — a terminal, a virtual machine, systemd units, a GitHub machine account, an access token. It has never once been handed to another human being.

That isn't a flaw in the process. That's the prototype finishing its job. The plugin was the proof. The control plane is the product.

An intake conversation that turns the idea in your head into a written problem, an audience, and a reason it's now. Then research you didn't do — market, competitors, what people pay, what break-even looks like — with citations you can click. Then both fold into a decision record with a recommendation.

The decision line stays empty. A person writes that.

Skip the whole thing in one click if you already know what you're building. It will still be here for the second idea — which is the one it is really for.

A product interview asks what it does, for whom, and what done means — and phases every feature into versions, so your first release is a real release and not everything at once.

An architecture interview asks how it is built, and writes the technical design and the decisions behind it.

Then the plan arrives: milestones, issues, acceptance criteria. Nothing starts until you approve it.

Move something, cut something, flag something as harder than it looks — then press start. That press is the only thing that begins autonomous work.

An issue is claimed. One agent reads only the acceptance criteria and writes a test that fails — it has never seen an implementation and cannot be shaped by one. A second agent is handed that failing test and told to make it pass. A third runs the suite, checks every acceptance criterion, and either merges it or sends it back.

Separate agents, separate briefs — because a test written by the thing being tested isn't a test.

Every five minutes, the queue is drained again. Nobody has to be awake for it.

The board shows what moved overnight — what merged, what is in review, what is blocked. Slide the pane open for the issue itself and the trail behind it.

Then the part no agent does for you: open the preview, use the thing, and file what's wrong. A defect re-enters the same queue and gets the same treatment — failing test first, then a fix, then a review.

When the machine genuinely cannot decide — a criterion that contradicts itself, a test the implementer cannot satisfy without changing the spec — it stops and rings. Not a log line you have to go and find.

If the code lives in your own repository, the same escalation reaches you through GitHub as well.