Case study · 2026 · Software Factory

Cut spec-to-shipped-feature time from weeks to days with a Software Factory run by agents.

This is my Software Factory. You decide what to build. Agents write the tests, the code and the proof. You try a working feature on the real backend and decide whether it ships.

Why a feature used to take a week

A feature used to pass through four people. A product manager wrote the spec, a designer drew it, a developer built it, and a tester checked it. Each handoff took days, and each one lost detail. For a startup, that means four salaries before one feature reaches users.

A Software Factory turns that pipeline into a repeatable process. In mine, agents do the work of each step, and the person who owns the product makes the decisions.

Three phases, and you are needed in two

Three phases: Define with you and the agents, Build with agents alone, Review with you. Findings from Review go back to Define.findingsDefineyou + agentsBuildagents aloneReviewyou
You take part in Define and Review. Build runs without you.
  • Define. You and the agents agree on what to build. The phase ends when you seal the contract.
  • Build. Agents build every story and prove it with tests. Nobody asks you anything in this phase.
  • Review. You try the feature. You accept it, or you send findings back to Define.

Define: you decide what gets built

Define in five stations: your idea, questions one at a time, a clickable prototype, acceptance criteria, and the sealed contract.IdeaQuestionsPrototypeCriteriaContract
From an idea to a contract that every later step is checked against.
  1. Your idea is checked against the code. An agent reads your idea next to the existing product. It lists what fits, what is already known, and what is still open.
  2. Questions, one at a time. Each question comes with a recommended answer. You decide, take the recommendation, or put the question off.
  3. The key flow. The agent writes the walk through the feature as user stories, and you confirm it.
  4. A clickable prototype. The prototype runs in the real app with mock data. You click through the feature before any backend exists.
  5. Acceptance criteria from the prototype. An agent reads the approved prototype and writes the criteria for each story: the steps, the rules for the data, and the states such as loading, empty and error. Every gap it finds becomes one more question to you.
  6. A collision check. An agent lists every place where the new feature changes existing behavior. For each one, you decide whether to protect the old behavior or change it.
  7. You seal the contract. Build does not start while any story has no criteria.

Build: agents work while you are away

Build runs once for every story, with no questions and no stops.

Build for one story: the tests are written first and all fail, agents build the feature, and the same tests all pass.Tests firstall failagents buildSame testsall pass
For each story, the tests exist and fail before the code that makes them pass.
  1. A browser test for every path. An agent writes Playwright tests: one for each path through the flow, and one failure case for every request the page sends. They must pass on the prototype's mock data first.
  2. Failing tests first. Another agent writes the tests for the data rules. They must fail before the backend exists, because a test that passes too early proves nothing.
  3. The real backend. An agent replaces the mocks with the real backend until every test passes, the browser tests included.
  4. Hardening. Review agents look for bugs and security holes, and each security finding gets its OWASP category. A serious finding is first proven by a failing test, then fixed. Hardening stops after three rounds at most.
  5. Screenshots of every state. An agent walks each flow and saves a screenshot of every state, stamped with the commit it shows.

A test status comes only from a real test run. Nobody can mark a test as passed by hand, not even the agent that wrote it.

Review: you try it on the real backend

Review: you try the feature. If you accept it, the pull request opens. Findings go back to Define as new criteria and new failing tests.acceptfindingsYou tryitPullrequestBack toDefine
Every finding becomes a new criterion or a new failing test before the fix.

You get the status and the screenshots, and then you try the feature yourself. Each finding gets one of four labels: a criterion was unclear, a criterion was missing, a test was wrong, or the request is out of scope. Findings about criteria and tests go back to Define, become new criteria and failing tests, and the story is built again.

When you accept the feature, the factory opens the pull request. The merge stays with you.

What this gives a founder

  • Your time goes into decisions. You answer questions, click through the prototype and review the result. Agents write the code and the tests.
  • You see the feature before it is built. The prototype runs in your app, so a wrong idea costs one conversation instead of a sprint.
  • Every requirement has a test. A browser test or a data test checks each acceptance criterion, and every test was seen failing before the code existed.
  • You get proof, not a status update. Every state of the feature comes with a screenshot from the running app.
  • Nothing is lost between sessions. Every decision, criterion and test result is stored with its history. Work can stop and resume without anyone retelling it.
  • Mistakes improve the factory. When an agent produces something wrong, I fix the instructions that produced it, so the same mistake does not come back.

Have an idea?

Book a call, and a prototype of your idea is built during that call. That is the Define phase, with you in the room.

← Back to the home page