In this article
The essential idea
A credible SaaS estimate connects a usable first journey to delivery effort, uncertainty and recurring operations. Break the scope into work packages, price the same assumptions and keep migration and support visible.
Estimate a journey, not a list of screens
Take an illustrative B2B booking service. A first usable journey lets an organisation invite a colleague, create a booking, avoid a conflicting reservation and receive confirmation. “Five screens” does not describe that work: invitations expire, permissions differ, two people can book simultaneously and an email provider can fail.
Define acceptance examples for each step. Can an administrator remove access? What happens after a failed confirmation? Which records must support see? These questions reveal the logic behind the interface. They also make supplier proposals comparable: one estimate may include recovery and administration while another silently assumes the happy path only.
The budget follows the scope
Cost categories to estimate, not a fixed-price quotation.
Product scope
User journeys, business rules and acceptance criteria.
Integrations and data
APIs, migration, permissions and external dependencies.
Operation over time
Hosting, support, security and future changes.
Build an explicit effort model
Here is a teaching scenario, not a quotation or a market benchmark: 8 person-days for discovery and design, 18 for the core booking journey, 10 for identity and integrations, 12 for verification and release, and 7 for administration and handover. The total is 55 person-days. Add an illustrative 11-day uncertainty allowance and the planning envelope becomes 66 person-days.
Multiply effort by the agreed blended day rate to form a labour budget; price licences and infrastructure separately. Person-days are not calendar days. Parallel work, part-time availability, feedback delays and dependencies change elapsed delivery time. The useful feature of this model is not its numbers but its visible assumptions, which a discovery phase can replace with evidence.
Where the illustrative 55 person-days go
Teaching assumptions, not a quote. Base effort: 55 days; uncertainty allowance: 11 days; planning envelope: 66 person-days. Calendar duration and external costs are separate.
person-days
Make the first release smaller without making it unusable
For the booking example, postpone multiple calendar providers, complex pricing rules and a self-service analytics builder. Keep conflict prevention, basic permissions, support visibility and a recovery path. Removing a secondary feature reduces scope; removing the ability to fix a failed booking transfers work to users and support.
A useful first release answers a product question: will teams actually coordinate bookings in this system? Instrument completion and abandonment, then interview users who returned to spreadsheets. Avoid funding a long catalogue of secondary capabilities before the central journey has been used. Conversely, a prototype that cannot handle real customer data should not be budgeted or presented as a production release.
Identify uncertainties that can change the estimate
An undocumented external API, inconsistent legacy data or unclear tenant isolation can change the architecture, not just add a few screens. Investigate these items early with a bounded technical experiment. For a calendar integration, test authentication, rate limits and conflict behaviour using a representative account before committing to an exact integration effort.
Keep a assumptions register: owner, evidence, decision date and budget impact. When an assumption fails, discuss a scope change rather than hiding the extra effort inside the original estimate. A range is useful only if everyone understands what makes the low and high cases different. Separate unknown requirements from an allowance for ordinary delivery variation.
Budget the months after launch
Recurring costs include hosting, storage, email delivery, monitoring, backups and external services. Human work includes dependency updates, support, incident handling and product changes. Model these separately from initial development and state the expected traffic, retention and service hours. An inexpensive hosting bill can coexist with substantial manual operations.
Ask for a handover that includes deployment instructions, access ownership, restoration evidence and the backlog of deferred work. Review actual usage after launch and replace assumptions with measurements. That creates a budget which can evolve with the product, rather than a one-time figure that stops being useful as soon as the first customer arrives.
FAQ / DECISIONS
Frequently asked questions
Can I start with a small budget?+
Start by reducing the decision boundary, not by hiding required security, recovery or ownership work. If the smallest safe slice does not fit, stop or choose another approach.