How to scope a first SaaS system in 14 days

Scoping a first SaaS system in 14 days is a subtraction exercise. Lock the date and the price, pick the single workflow that proves the business, then cut everything that does not serve it. If what remains still does not fit two weeks, say so before anyone starts building.

Most first products fail the calendar before they fail the market. The scope grows because nobody wrote down what "done" meant, and the date was a hope rather than a constraint.

Lock the date and the price first

If the feature list comes first, the date is whatever the list turns out to cost. Invert it. Agree the two weeks and the fee, and treat both as fixed walls. Every scope conversation after that is about what fits inside them.

This changes who makes the hard call. Instead of a developer quietly absorbing three extra screens, you decide which three screens matter. That is the right person deciding.

Start with one workflow

Pick the journey that proves the business. Not the settings page, not the admin rebuild, not the five integrations that would be nice. One user, one job, one outcome you can click through on a staging link.

Write it as a sequence of screens and states. If you cannot list them on a page, you do not have a v1 yet, you have a theme.

A worked example: Job Hunt is a two-sided hiring product, which sounds like a large build. The v1 scope was the loop that proves it works. Candidates search open roles by keyword and location, employers publish and manage their own listings, and the two account types stay separate. Everything a hiring platform eventually needs sat outside that loop.

Two-sided marketplaces are the common trap here, because it is tempting to build both sides fully. You do not need both sides fully. You need one path through each side that meets in the middle.

Count the surface

Scope arguments feel subjective because people describe features in adjectives. Numbers end the argument. Before quoting, count:

• User types who log in, and the roles inside each one
• Screens, listed by name, including empty and error states
• Third-party connections you cannot launch without
• Objects in the data model, and which roles write to each one
• Decision points where someone approves, rejects or assigns

If that list does not fit a 14-day build with design, QA and handover included, it is not a 14-day build. It is two or three sprints, and saying so at the start is cheaper than discovering it in week two.

Xntral is the honest version of that maths. Users, patients, locations and functions in one workspace, plus recurring appointment scheduling against those records, came to five modules. That ran as four sprints across 56 days. The counting told us that before the first sprint, so the plan matched the surface instead of fighting it.

Write acceptance criteria you can click

"Search works" is not a criterion. It is an opinion waiting to be disputed at handover. A criterion is a sentence with a subject, an action and a visible result:

• An employer with no listings sees an empty state with a button to post their first role
• A candidate searching a keyword with no matches sees a message, not a blank page
• A logged-out visitor hitting a private URL lands on login, then returns to that URL after signing in

Three or four sentences per screen is enough. The test is simple: could someone who was not in the meeting open the staging link and tell you whether it is true?

Define handover as part of the spec

"Done" is not a demo. It is a repo you own, a deployment you can reach, and notes a stranger on your team could follow. Put those in the quote and in the timeline. Otherwise the last three days disappear into "we will tidy that up after launch", which is the phase nobody pays for.

A handover that holds up includes:

• Source in a repository under your account, not the builder's
• Environment variables documented, with the list of accounts and keys the app needs
• A deploy you can trigger yourself, and a note on how to roll back
• A short README covering the data model and the parts most likely to change next

If a build does not end in source, access and docs, you bought a different kind of subscription. That argument is worth its own read in when to build custom software instead of buying.

Park new ideas in the next-sprint list

New ideas during the build go on a list. They do not enter the current sprint. That is the whole mechanism that keeps the date honest.

The list is not a graveyard, and treating it as one is why founders resist it. Most items on it are good, and some become the next sprint. What the list protects is the promise that the current two weeks end on the date you published.

The one exception worth allowing: if a new idea makes something in the current scope unnecessary, take it. A swap that removes work is not scope creep.

A scoping checklist

Run this before you sign anything:

• The date and the fee are written down and neither moves
• One workflow is named, and one sentence says what it proves
• Every screen in that workflow is listed, empty and error states included
• Each screen has acceptance criteria someone could check on staging
• Integrations are limited to the ones the workflow dies without
• Auth and roles are decided, and the role list is short
• Billing is either in scope with a named plan and price, or explicitly out
• Handover artefacts appear in the deliverables, not in a footnote
• Everything else is on a written next-sprint list

When 14 days is the wrong answer

Two weeks is a shape, not a promise you can force onto any product. Be honest about the cases where it does not fit: a migration off a live system with real customer data, a compliance requirement that needs review cycles you do not control, or a workflow with more than a handful of roles that all approve different things.

In those cases the answer is not a longer, vaguer project. It is a first sprint that ships a genuinely useful slice, then the next one. That is how a five-module system gets built without a six-month runway of nothing shippable.

If you are working out what to build inside the two weeks once the scope is set, SaaS MVP architecture covers the shape of v1, and Stripe billing for SaaS MVPs covers the smallest billing setup that takes money.

If you want help cutting a first system to a date you can publish, book a discovery call or read how a fixed-scope SaaS MVP build runs.