SaaS development: from idea to a product you sell

Test demand before you build the whole platform

The riskiest part of a new SaaS product is rarely the code. It is whether enough customers will pay for it. A first version for a few pilot customers answers that before the bigger investment.

A sensible SaaS MVP covers the one job customers would pay for, with accounts set up by you rather than self-service sign-up, and simple invoicing. Pilots who pay something, even a reduced price, tell you far more than pilots who use it for free. If the product is mostly forms and a spreadsheet, a no-code prototype may be enough to test interest first, and we will tell you so. Our discovery and MVP development page explains how that first stage is scoped.

Decisions that are expensive to change later

A SaaS product can start small, but some foundations are hard to retrofit once customers are using it. These are settled in writing before the build starts:

• Multi-tenancy: whether customers share one database separated by tenant, or each gets its own. The first is cheaper to run; the second suits customers who demand stronger separation.
• Roles and permissions inside each customer account, and what your own support staff can see.
• The pricing model: per seat, per usage, or tiers with limits, because the product has to measure and enforce it.
• Audit history of who changed what, which business customers increasingly ask for.
• Data export and deletion per customer, for when one leaves.
• An API or integrations with the tools your customers already use, such as Xero, Sage or their CRM.
• An admin panel for onboarding, usage, plan changes and support.

Subscriptions, billing and your customers' data

Billing is a product feature in its own right: trials, upgrades and downgrades mid-month, failed card retries, VAT on invoices and receipts. Most UK SaaS products use a payment provider rather than building this. Stripe's UK page, for example, lists Billing at 0.7% of billing volume on pay-as-you-go, on top of payment fees such as 1.5% + 20p for standard UK cards. Those percentages belong in your pricing model from day one.

Once business customers store personal data in your product, you usually act as their processor under UK GDPR. The ICO's guidance sets out what the controller-processor contract must include: processing only on the customer's documented instructions, confidentiality, security measures, and authorisation before using sub-processors such as hosting or email providers. In practice the product needs a data processing agreement, a list of sub-processors, per-customer export and deletion, and access logs. Check the details with your adviser.

Owning the code, and what shapes the cost

If the product is your business, the code has to be yours. The repository sits in your company's name from day one and the IP is yours, which matters when an investor or buyer carries out due diligence, or when you later bring development in-house. The guide how much custom software costs explains how a price is built and gives market reference figures. For SaaS development the factors that weigh most are:

• How much of the product is in the first version, and how much waits for pilot feedback.
• The tenancy model and the separation your customers require.
• Self-service sign-up and billing, or accounts set up by your team.
• Integrations your customers expect on launch.
• Reporting inside the product for your customers and for you.

How we would build your SaaS product

A consultancy could turn its internal tool into an MVP for three or four pilot clients, and add plans, card payments and self-service sign-up only once those clients renew. You see the product working at a demo every two weeks, under one fixed price per project. The method is on our page about fixed price software development.