How it works
SaaS Factory keeps one clock — the days between your idea and your first paying customer. This page walks the journey that clock measures: the moments where a friction between you and revenue gets removed. Knowing what to build. Getting it built without a dev team. Everything a product needs before it can earn. One URL goes in; a live company that can take money comes out — with the cost of every feature on the record.
Learning friction
The first friction is knowing what to build. Paste a company's URL into the Opportunity Engine and it returns a market analysis with the product ideas attached — adjacent products, the ones your existing customers already use, and downstream products, the ones your customers' customers need. You arrive with a hunch; you leave with a shortlist.

The ledger
Revenue only counts net of what it costs to earn. Every run is metered: each stage timed, the agent spend counted, the total pinned to the feature it built. Most teams can say what engineering costs per month; here you can point at one feature and answer to the cent. Failed runs sit on the same board, in red — visible, not buried. What a plan costs is on Pricing.

Your part
Pick the product and write one mission statement — what the company is for, in your words. The Product Owner agent answers with a feature set, a tech stack and a build plan, then starts building it out. From there your job is direction, not delivery: you choose what gets built and how much initiative the team takes. The dial has three settings, described here in the product's own words —
Off Your team acts only when you ask.
Maintain Fixes, feedback and updates ship themselves. Nothing new gets built.
Perfect Your team finds, picks and ships improvements on its own.
Technical friction
The second friction is the building itself — the hiring, the tooling, the release management that stall a product for months. Here the stages run in order, every time: discover, implement, test, review, deploy. Each has one job and its own gate — work that fails a gate goes back; it does not go through.
An agent reads the product as it already exists — routes, schema, patterns — and turns your sentence into a spec with acceptance criteria before a line of code is written.
An implementer writes the change on the platform's rails — the shared UI system, the same conventions the rest of the product uses — so the diff reads like it belongs.
Unit, integration and end-to-end tests ship in the same diff as the feature, and the run does not advance until they pass.
A reviewer agent reads the diff the way a senior engineer would — correctness, security, fit with the codebase — and sends work back rather than waving it through.
The change goes to production, the release is recorded, and the run's cost — every stage timed, the agent spend counted — lands on the feature card.
That pace is not a launch-week sprint; it is the steady state. Feedback a customer sends in the morning can be shipped software by evening —
Setup friction
The third friction is everything a product needs before it can earn: infrastructure, accounts, payment rails. At first login the full stack is already provisioned — auth, database and payments, live — and the marketing site ships with payments wired in, so the first customer who wants to pay, can. That is a statement of fact, not a promise: our first product, Making Tax Digital, charges £9.99 a month today and has a paying customer. Your first £, €, $ and ¥ is the moment the company becomes real — and nothing here is allowed to delay it.
Revenue, once it exists, is worth defending. AI can copy your product; it is harder to find and copy what your moats know and do. Every company built here is built with three, and the agent team — a moat strategist and a data-flywheel agent among them — keeps working on them for as long as the product runs, tracking competitors as it goes.
The jargon, the edge cases, the regulation — what only someone inside the vertical knows.
Founders, agencies, operators
The journey is identical in each case. What changes is the job it is doing — and where the human attention goes.
You have the idea and the domain knowledge, not a dev team. Describe the product; the pipeline builds it while you keep your day job. What shipped is reported back in plain language and you say what comes next — one founder plus the agents, however big it grows.
Client products die in maintenance, not in build. Run each client's product as its own pipeline with its own ledger — when a client asks what a change will cost, you answer with a number from the last one.
Attention is your constraint, not code. The grid below shows every product's release state, health and platform version at a glance — set the steady ones to Maintain and keep your eyes on the one that is growing.

The repeatable workflows your customers hand over, run by you or your agents.
The signals that show which features to build next, feeding straight back into the other two moats.
