The running system
In production- Frontend, backend, mobile, integrations, infrastructure
- Built in your repos, deployed to your cloud
- Inside your security and access controls
- Automatic rollback ready
Stage 2 · Lights-out execution
From approved product to production. Without your team in the room.
You bring the product your people approved in the Product Discovery Studio. The Factory specifies it, builds it, tests it and deploys it to your cloud in three to four weeks.
Your team comes back once — to review the evidence and say go.
-
Week 0 · You
Approve the product
In the Product Discovery Studio. Every screen, every role, signed off.
-
Weeks 1–4 · The Factory · lights out
It gets built, tested and deployed
- Specifications
- Technical design
- Tasks
- Code
- Tests
- Staging
0 hours from your team
-
Week 4 · You
Review the evidence. Go or no-go.
About an hour. Every approved behavior, with the tests that prove it.
-
Then
Live in production, in your cloud
01
The approval is the input
Every build used to begin with a translation. This one begins with an approval.
In the old model, approval is where the re-reading starts. The PRD becomes tickets, the tickets go to teams, and each team builds its own version of what it read. The gap shows up in UAT, after the budget is spent.
Here, nothing is handed to anyone. The product your people clicked through, the PRD generated from it, the decision record behind it and your architect's trade-offs go into the Factory whole. It holds all of it at once — the same context, from the first specification to the release.
The Studio made the requirement executable. The Factory executes it.
The old way
- Approved PRD
- split into tickets
- staffed across teams
- each team reads it its own way
- integrate
- UAT
- "that's not what we meant"
The Dark Factory
- Approved product
- one context, read whole
- specified, built and tested together
- every behavior proven
- evidence review
- production
01
The approved frontend
Every screen, every role, every workflow. It becomes the acceptance test.
02
The PRD
Generated from the product, so the build reads what your users saw.
03
The decision record
Every question already answered, with its owner. The Factory reads the record, not your calendar.
04
The architecture choices
Your architect picked from options with their implications. The Factory checks each one against the rest of the system.
02
How the build runs
One system, holding the whole context. Nothing to hand off.
The work that used to belong to six teams runs as one continuous system. No step has to explain itself to the next, so no step waits for the next: tasks run in parallel, and tests are written with the code, not after it.
-
Stage 1 · done
01Scope & Prototype
PM
-
Stage 1 · done
02Architecture Trade-offs
Architect
-
Stage 2 · lights out
03Autonomous Build
Factory
-
Stage 2 · human gate
04Validate & Ship
QA
03Autonomous Build · Factory
Lights out · 3–4 weeks · 0 hours from your team
-
01
Specifications & user stories
From the approved product and the architect's decisions.
-
02
Technical design
The full system design, from the architect's choices.
-
03
Task decomposition & sequencing
Features become tasks. Dependencies mapped, order set.
-
04
Code generation
Frontend, backend, mobile, integrations, infrastructure. In parallel where possible.
-
05
Testing
Unit, integration and end-to-end. Test-driven throughout.
-
06
Deployment to staging
Once every task passes.
-
04 · Validate & Ship · QA
The lights come on for one decision.
QA validates the build on staging against its evidence. Anything flagged goes back to the Factory, which resolves it. Go, and it deploys to production — automatic rollback ready.
The lights are off because nobody needs to be in the room.
03
The proof is built in
Every approved behavior becomes something the system must prove.
Testing is not a phase at the end. Every artifact the Factory produces is measured against what it must contain to be complete — before and after it is generated — and regenerated until it passes. Here is one decision from the Studio, followed through the build.
-
01Decided in the Studio
3.2 Override authority
Regional managers may approve exceptions ≤ 8% within their region. Above 8% routes to Finance.
↳ decided day 3 · owner: VP Finance -
02Specified
- FRS 3.2 · override authority
- API contract · approve exception
- Data model · region, discount, approver
-
03Tested
- Acme Corp · 6% · own region → approve
- Fabrikam · 7.5% · own region → approve
- Northwind · 11% → routes to Finance failed · regenerated · passed
- Another region → not in the queue
- Auditor → read-only, cannot approve
-
04Evidence
5 of 5 passing
3.2 Override authority · traced to the decision of day 3 · VP Finance · attached to the release
Illustrative. The rule, accounts and roles are the pricing-exceptions example from the Product Discovery Studio.
The standard, on every build
- Test-driven development
- Specification-first development
- 95%+ code coverage
- Full regression on every release
- Automated end-to-end testing
- Continuous integration
- Automatic rollback
- Audit trails and compliance
A machine does not skip the paperwork. Security, observability and compliance are part of the pipeline from the first generated line, not reviewed in at the end.
Why it's different
Copilots make each team faster. Lights-out execution removes the handoffs between them.
04
Your team's time
Zero hours. Then one decision.
The build is where the old model pulls your people back in — to clarify tickets, re-explain the decision to a new team, sit through UAT. Here the questions were answered in the Studio and live in the decision record. For three to four weeks the Factory needs nothing from your team. Then QA reviews the evidence, in about an hour, and makes the call.
Traditional
build, then UAT
Build · tickets, clarifications
UAT · re-decide
Dark Factory
0 h until the gate
Go or no-go in week 4. The row above is still building.
Illustrative, for a single mid-size initiative.
Before the build · PM
Approve the product
Before the build · Architect
Pick the trade-offs
Lights out · 3–4 weeks
0 hours from your team
At release · QA
Go or no-go, against the evidence
Your people hold the gates. Everything between them is execution. Lights out on execution. Never on authority.
05
What ships
The system you approved. And the proof that it is.
The release evidence
Attached- Test results and coverage
- Full regression status
- Every approved behavior traced to its tests
- The decision record, carried through
The living context
SynchronizedKept in step with production, every sprint:
- The clickable prototype — always matches production
- The specification suite — 20+ documents per component
- The mock environment — every dependency simulated
Yours to keep
Nothing to hand over at the end.
It was built in your repos and your cloud from the first commit. The code, the specifications, the evidence and the decision record are already yours. No handover project. No knowledge left inside a vendor's team.
06
After go-live
Change it in the same screens. It ships again.
After go-live the loop is the same two stages, shorter. Change the product in the Studio, approve it, and the Factory rebuilds, re-proves and redeploys what changed.
Same day median turnaround for a change after go-live
-
01 · Studio
Change it
In the same screens your people approved.
-
02 · Your team
Approve it
The change is a decision, recorded like the first ones.
-
03 · Factory · lights out
Rebuild and prove
What changed is rebuilt. The full regression runs again.
-
04 · QA
Release
Go or no-go against the new evidence.
↺ and again, for the life of the system. Maintenance is the same two stages, repeated.
Your people decide what should exist.
The Factory builds it, proves it and ships it.
Approve the product. Review the evidence. Everything between is lights out.
Approved product in. Production software out, with its evidence. Three to four weeks.