Estimates for a SaaS MVP are usually wrong in a predictable direction and for a predictable reason. The features get estimated carefully, because features are what everyone discusses. The platform underneath them - authentication, tenancy, roles, billing, admin tooling, email delivery - gets a nod and a small number, and then consumes half the project.
01The platform is most of the work
Every B2B SaaS product needs the same foundation before the first differentiating feature is useful: sign-up and sign-in, organisations, invitations, roles and permissions, billing and plan limits, an admin view for your own support team, transactional email that reaches inboxes, and audit logging.
None of that is on the roadmap because none of it is why anyone buys the product. All of it is required before anyone can. On a typical first release it is somewhere between forty and sixty percent of the engineering effort, and it is the part that gets estimated at two weeks.
| Area | Share of effort | Frequently underestimated |
|---|---|---|
| Auth, tenancy, roles | 15-20% | Yes - permissions get complicated fast |
| Billing and plan enforcement | 10-15% | Yes - proration and failed payments |
| Core differentiating features | 30-40% | No, this is what gets estimated |
| Admin and support tooling | 5-10% | Yes - usually forgotten entirely |
| Infrastructure and deployment | 10% | Sometimes |
| The last mile to production | 15-20% | Almost always |
02The last mile is not a rounding error
There is a long gap between the last feature working on a developer's machine and a product a stranger can pay for and rely on. Error handling on paths nobody tested, empty states, loading states, email deliverability, mobile layouts, accessibility, monitoring, backups, and the security work that a first enterprise customer will ask about.
This is where projects overrun, and it is where the pressure to cut is highest because the product looks finished. Cutting it produces a demo rather than a product, and the shortfall surfaces during the first customer trial rather than during development.
03Scope creep versus scope discovery
Scope creep is adding things nobody needed. Scope discovery is finding out that the thing everyone assumed was simple has six cases - what happens when an invited user already has an account, when a subscription payment fails, when an admin removes themselves from the only organisation.
Discovery is unavoidable and should be planned for rather than treated as a failure of estimation. A contingency of twenty to thirty percent on a first release is realistic, and quoting without one is how fixed-price projects turn into difficult conversations at week ten.
| Shape | Elapsed | Team | What it includes |
|---|---|---|---|
| Thin slice, one workflow | 8-12 weeks | 2-3 engineers | Auth, one core flow, basic billing |
| Standard first release | 16-24 weeks | 3-5 engineers | Full platform, 2-3 workflows, admin |
| Integration-heavy | 24-36 weeks | 4-6 engineers | Above, plus external system integrations |
| Regulated or enterprise-first | 30-52 weeks | 5-8 engineers | Above, plus SSO, audit, compliance |
04What genuinely reduces cost
Buying the commodity parts. Authentication, billing and transactional email are solved problems, and building them yourself costs weeks and adds permanent maintenance. The build-versus-buy calculation almost always favours buying for anything that is not your differentiator.
Cutting workflows rather than cutting quality is the other lever. One workflow done properly beats three done partially, because a partial workflow generates support burden and gets abandoned by users. The instinct to trim polish across everything produces a product that feels uniformly unfinished.
05Questions to ask about any estimate
Does it include authentication, tenancy, roles and billing as line items, or are they assumed? Does it include admin tooling for your support team? Does it include the last mile? Does it carry contingency, and is that contingency stated rather than hidden inside the feature numbers?
An estimate that answers all four is more likely to hold. One that presents only feature work with a small platform allowance is describing a demo timeline, and the difference will show up as a conversation about scope somewhere around week twelve.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer