Contents
A SaaS budget needs to cover the product customers use and the service your team operates. The first release may have a narrow feature set, but it still needs an agreed approach to accounts, access, support and continuing delivery. Build the estimate from those responsibilities rather than comparing headline prices for applications with different scopes.
Define the first customer journey
Describe how a customer starts, completes the core task and receives value. Include setup, invitations and administration where they are part of that journey. Identify which tasks your team will handle manually at first and who is responsible for them.
Separate the first audience from possible future markets. A product for a small supervised pilot may need different onboarding and support arrangements from a service available to any organisation. State the intended release conditions so each estimate describes the same product.
Make account and access assumptions explicit
Explain whether customers are individuals, organisations or groups within organisations. Describe who can invite members, assign roles and access records. If one person belongs to several customer accounts, define how they move between them and which actions are allowed in each context.
Ask the team to explain how those boundaries will be implemented and verified. Include administration and support access in the discussion. A simple-looking interface can conceal important account rules, and those rules affect both implementation and testing effort.
Scope the commercial journey
Decide what the first release needs for trials, subscriptions, invoicing and access to paid capabilities. Describe changes as well as initial purchase: an upgrade, cancellation, failed payment or account closure. Involve the relevant commercial and finance owners in confirming the intended behaviour.
Identify which responsibilities a payment or billing provider will handle and which remain in your application. Ask for the integration, testing and operational work to be included in the estimate. Using an external provider does not by itself define how your product should respond to every commercial event.
Separate build, launch and continuing work
Break the initial investment into discovery, design, implementation, verification and launch preparation. List dependencies and assumptions alongside each part. Include data import, customer setup and support preparation when they are necessary for the first usable release.
Keep ongoing development and maintenance visible after launch. Establish who reviews feedback, prioritises improvements and maintains the software and its dependencies. Distinguish a support arrangement from a commitment to deliver new features; the same monthly amount can describe very different responsibilities.
Model operating costs against plausible usage
List the services required to operate the product, such as hosting, storage, email delivery and monitoring. Identify the usage assumptions that affect each cost and who will review actual consumption. Check current supplier terms for the specific architecture and plan when preparing the real budget.
Include your own team's work: onboarding assistance, support requests, billing queries and incident response. Consider an initial usage scenario and a larger one, making the assumptions explicit. Avoid presenting customer count alone as a complete cost model when customers may use the product very differently.
Use the budget to choose the next commitment
Ask which uncertainties could materially change the estimate and how they can be investigated. A focused account-model review, integration trial or user exercise may provide more useful evidence than immediately estimating every future feature.
Agree what the first investment should demonstrate and when the plan will be revisited. Compare actual operating effort and user outcomes with the assumptions after launch. Keep the next phase grounded in that evidence rather than treating the original budget as a permanent forecast.
An illustrative SaaS delivery and operating budget
Assume a fictional B2B SaaS product with two roles, one paid plan, organisation access boundaries, a browser interface and a single billing provider. Allow 10 person-days for discovery and design, 45 for product and backend work, 15 for verification and launch, and 5 for handover: 75 days. At an invented blended £650 per day, delivery is £48,750. Holding 20% contingency adds £9,750, giving £58,500 before VAT. This is a planning exercise, not a Veda quotation or market average.
Separately assume £400 a month for infrastructure and services plus £1,500 a month for a defined maintenance allowance: £22,800 a year. Payment transaction fees, sales, customer service, legal review and new features are excluded and need their own budgets. Do not label all ongoing work hosting; customer administration and exception handling remain real responsibilities even when the software is small.
Change one assumption at a time. A second billing model may affect entitlements, proration, support and testing, not just another pricing card. Ask the supplier to show that added scope. Check whether the first pilot needs automated billing at all, or whether a clearly operated manual arrangement can test demand. Reduce scope knowingly rather than treating an illustrative total as a commitment to unlimited product development.
How this relates to Veda Software’s work
Infinity Club’s published subscription and offer mechanics show why the operating service belongs in a product brief. The case supplies no SaaS budget, transaction fee or effort benchmark.