Blog Overview
Twelve weeks is enough for a product with one flow and two roles. The four preconditions, a week-by-week plan, and five reasons a project slips to twenty weeks.
Every founder wants to launch a SaaS product in twelve weeks. Some succeed, most do not, and the reason is not team speed. The reason is that the twelve weeks are planned as a build project, when they are really a deletion project: what do we remove so the product reaches its first paying customer?
This article explains what must be true to hit twelve weeks, what pushes a project to twenty, and what week one and week twelve look like. Our published band is SAR 25,000 to 35,000 over 12 to 20 weeks. Twelve is the lower edge, not the default promise.
What has to be true
Four conditions. First, the problem is known, not assumed: at least ten interviews with people who will pay. Second, the core service can be delivered manually at first, even if the product automates it later. Third, you have two or three customers ready to try and pay. Fourth, the decision-maker is one person, not a committee.
If one is missing, the project is not a build. It is research. Research has a different budget and timeline. Confusing the two is the most common dispute between founder and agency: the founder thinks they are buying a product, the agency builds exactly what was asked, and the result is a product nobody uses.
The twelve-week plan
The plan assumes a small team: product and design, two to three engineers, and direct access to users. With a smaller team, the weeks move, not the stages.
| Weeks | Work | Output |
|---|---|---|
| 1–2 | Ten interviews, problem definition, core flow map, the “we will not build” decision | Scope memo and first prototype |
| 3–4 | Flow design, interactive prototype, testing with five users | Approved core flow design |
| 5–7 | Build auth, roles, core data, and the flow | A working internal version |
| 8–9 | Billing or subscription, notifications, and admin panel | A usable release |
| 10 | Testing with first users, fixing blockers | Closed problem list |
| 11 | Security, backups, monitoring, and a simple marketing page | Operational readiness |
| 12 | Limited launch to ten customers, measurement, decision session | First recurring revenue |
What pushes the project to twenty weeks
Five things consume weeks without appearing in the first proposal. First, multiple roles: each adds navigation, permissions, and empty states. Second, external integration: each needs an interface contract, error testing, and a sandbox. Third, compliance requirements: data retention, audit, and breach reporting. Fourth, payments: a local gateway, invoices, refunds, and testing. Fifth, a redesign halfway through because users did not understand the idea.
The last is the most expensive because it cannot be planned for. It can be reduced by testing the prototype before writing code, not after. Five users in week four are cheaper than a rebuild in week ten.
What stays out of the first release
From reading to shipping
Want this built, not just explained?
Bring us the problem behind the article. We will tell you what it takes, what it costs, and whether we are the right team.
The “we will not build” list is the most important document in the project. Write it in week one and put it where everyone sees it. Examples of what can wait: a mobile app, advanced reporting, a custom analytics dashboard, multiple languages, ERP integration, invoice automation, a complex permission system, and in-product customer support.
Deferral is not neglect. It is sequencing. A product that reaches its first paying customer gives you information that six months of planning cannot. The second version is built on what you learned, not what you imagined. To compare subscription and licensing models, read multi-tenant SaaS architecture after this article.
How to measure week twelve
Do not measure by features or lines of code. Measure three numbers: customers who paid, the share who completed the core task on the first attempt, and the share who returned in week two. The first proves demand. The second proves the product works. The third proves the value repeats, and that is the number that matters in a subscription model.
If three customers paid and none returned in week two, the problem is not marketing. It is value or experience. If users returned and nobody paid, the problem is pricing or clarity of benefit. Each number leads to a different decision, which is why it must be measured from week one, not after launch.
Put these numbers on one dashboard the whole team sees, not in a report someone opens on request. A visible number becomes a decision; a hidden number becomes an opinion. Decide in advance what you will do if the result is bad: adjust pricing, narrow the segment, or stop the feature. A decision written before the result beats a debate after it.
Before you start
Ten documented interviews. With people who will pay, not the founder's friends.
One sentence for the problem. If you need a paragraph, the problem is not clear yet.
Three prospective customers. Names, not a market segment.
A pricing model decision. Monthly, annual, or licence. Each changes the build.
The “we will not build” list. Written and signed by the decision-maker.
One product owner. One person accepts or rejects changes.
An operating budget. Hosting, email, monitoring, payments, and support.
One success metric. Paying customers, or task completion. Not both.
Frequently asked questions
Is twelve weeks realistic? Yes for a product with one flow, two roles, and one payment integration. No for a multi-role, multi-integration product.
Can we launch without billing? Yes in a trial, but the first paying customer is what proves demand.
Should we build a mobile app with the first release? No, unless the core value can only be delivered on mobile.
How long is a full launch? The published band is 12 to 20 weeks, depending on roles and integrations.
What happens after week twelve? A decision: expand, adjust, or stop. The decision is built on real usage, not opinion.
Sources
- Atlassian: Agile — short delivery cycles and scope control.
- web.dev: Web Vitals — the performance thresholds we test against.
- PDPL implementing regulation — what belongs in the first release.
- SaaS platforms — our build and operate scope.
- Client portal development cost — a comparable scope.
