A SaaS proposal can describe every customer screen while missing the parts that make the product operable. Tenancy, onboarding, billing states, support, monitoring, privacy and customer exit belong in the service from the start.
01
SaaS development is more than a web application with billing
Ordinary business software usually serves one organisation. A SaaS product serves several customer organisations through one managed service.
That changes the design. The software needs to understand the difference between a user and a customer account. A customer organisation may have several people, different roles, its own settings, a subscription level and a clear boundary around its information.
The word for that customer boundary is often “tenant”. A tenant might be one company, one department or another group that buys and uses the service. It is not simply the person who signs in.
This distinction reaches into identity, permissions, data storage, reporting, support, billing and monitoring. It is one reason AWS describes SaaS as a business strategy rather than a single technical pattern. There is no universal architecture that suits every SaaS product. The domain, customer expectations, regulatory position, price and operating model all shape the answer.
02
Start with evidence that the service deserves to exist
Architecture is a tempting place to start because it feels concrete. Teams can debate cloud providers, microservices and databases long before they have proved that a buyer will pay for the workflow.
A better development service starts with product evidence.
Suppose a company wants to create a maintenance coordination product for regional service businesses. Each customer would manage sites, jobs, engineers, photographs, approvals and customer updates. The first question is not whether the platform needs serverless functions. It is whether maintenance teams have a repeated problem that is important enough to change how they work and pay for a solution.
Discovery should identify the buyer, the people doing the work, the first complete workflow and the current alternatives. A clickable prototype, a manual pilot or a limited working product can test assumptions before the full service is built.
This work should leave useful evidence behind: a defined first customer, a small set of outcomes, known risks, a prioritised scope and a reason for each major feature. A long backlog is not the same as a validated product.
03
Define the customer account before designing every screen
Many avoidable problems begin with an unclear account model.
For the maintenance product, is a tenant the service company or one of its branches? Can a customer belong to several branches? Can a subcontractor work across several customer accounts? Who can invite users, change permissions or view commercial reports? What happens if the person who created the account leaves?
These questions determine the data model and permission system. They also affect pricing. A product sold per company behaves differently from one sold per location, user, active job or usage unit.
The model should cover the customer organisation, its users and roles, its data boundary, the features and limits in each plan, the people allowed to manage access and the route for suspension, export and closure.
If these rules are vague, the application will accumulate exceptions. One customer will need a special database field, another will receive a private version of a screen and a third will require a manual permission change every month. That is how a supposedly scalable service becomes several custom applications wearing the same logo.
04
What a complete SaaS development service should cover
The deliverables will vary by product, but the following areas should be visible in the scope. If one is excluded, the proposal should say who owns it and when it will be handled.
| Capability | Decision to make | Useful delivery evidence | Risk when it is missing |
|---|---|---|---|
| Product validation | Which buyer, problem and first workflow are worth funding? | Research notes, prototype findings and a prioritised first release | A well-built product solves a weak or unproven problem |
| Tenancy and identity | What is a customer account and who can access its data? | Account model, roles, permission rules and isolation tests | Users see the wrong information or support relies on manual fixes |
| Onboarding | How does a new customer become ready to use the service? | Repeatable account creation, invitations, setup checks and sample data | Every sale creates a new implementation project |
| Billing and entitlements | How do plans, trials, limits and payment states affect access? | Billing events, access rules, failed payment handling and test cases | Finance, product access and customer communication disagree |
| Core workflow and data | What is the smallest useful end to end job? | Working product slice, data model and acceptance scenarios | Screens exist but the customer cannot complete real work |
| Deployment and quality | How does a tested change reach customers safely? | Automated checks, environments, deployment process and rollback route | Releases become stressful and faults are harder to contain |
| Monitoring and support | How will the team know which customers are affected? | Tenant-aware logs, alerts, support tools and incident notes | The service looks healthy while one customer is unable to work |
| Data exit and closure | What happens when a customer leaves? | Export format, retention rules, deletion process and closure record | Customers become trapped and information is retained without purpose |
The table is not a demand to build everything at maximum scale on day one. It is a reminder to make each decision deliberately.
05
Choose a tenancy model that fits the business
Multi-tenancy does not mean every customer must share every technical resource.
A pooled model may share application and database resources while enforcing a tenant boundary in the software and data access rules. A siloed model may give a customer more dedicated resources. A hybrid model may share most of the platform while isolating particular customers, workloads or data.
Each choice has consequences. Greater isolation can help with specific performance, residency or regulatory needs, but it usually increases cost and operational work. Greater sharing can improve efficiency, but it requires careful access controls, testing and visibility into the “noisy neighbour” effect where one customer's workload affects another.
The right answer may also change as the product grows. Azure's multitenant guidance treats compute, storage, identity, networking, deployment, governance and cost as connected decisions. It does not prescribe one database pattern for every product.
That is why “we use microservices” is not proof of SaaS maturity. A well-structured modular application can be a better first architecture when it is easier to understand, test and operate. Separate services become useful when they solve a real scaling, ownership, reliability or deployment problem, not when they make the proposal sound more expensive.
06
Billing is a product lifecycle, not a checkout button
Subscription billing introduces more states than paid and unpaid.
A customer might be in a trial, waiting for the first payment, active, overdue, scheduled to cancel, cancelled or temporarily unable to pay. They may upgrade immediately, downgrade at renewal, add users halfway through a billing period or change the card after a failed payment.
Stripe's subscription documentation shows why applications need to react to billing events rather than trust the last page the customer saw. A payment can require further action or fail after the user has left the checkout. Webhooks need to update the service reliably, and processing them should be safe if the same event arrives more than once.
The commercial rules need human language before they become code. Does a failed payment remove access immediately or begin a grace period? Can a suspended customer still export data? Which features change after a downgrade? Who is told about the problem? Can support correct an account without editing the database by hand?
These are product and customer service decisions. The payment provider can collect money, but it cannot invent the operating policy.
07
Build the support surface alongside the customer product
SaaS teams naturally spend most design time on customer screens. Internal support and operational tools often arrive later, after the first difficult account problem.
The service team needs a safe way to find a customer account, see its plan and recent activity, understand failed jobs, resend an invitation, review integration status and record an action. Sensitive support access should be controlled and audited. If staff can act as a customer for diagnosis, that ability needs clear permissions, visible use and an automatic end point.
For the maintenance product, support should be able to see whether a customer imported a site, which permission blocked an engineer, whether a photograph upload failed and whether an external integration has stopped authorising requests.
Without this operational view, support becomes guesswork. Developers inspect production data manually, customers repeat the same story to several people and every incident takes longer than it should.
08
Test the service boundaries, not just the happy path
Feature testing proves that the intended action works. SaaS testing also needs to prove that the wrong customer, role or subscription state cannot perform it.
Important tests should confirm that one tenant cannot view another's data, role changes apply everywhere, a new customer can onboard without developer intervention, billing events can arrive twice or out of order, failed jobs can be retried safely, backups can be restored, releases can be rolled back and account closure follows the agreed export and retention rules.
Load testing matters, but scale is not only the number of requests per second. A large import, an expensive report or one poorly configured integration can affect other customers. Tests should reflect the work customers really perform.
09
Monitor the customer experience, not just the server
A green infrastructure dashboard can hide a broken service.
The application may be online while onboarding emails are not being delivered, one tenant's integration is failing or a background queue is delaying every job for customers on a particular plan.
Tenant-aware monitoring connects technical events to the customer affected. Logs and metrics should carry the tenant identity where appropriate without exposing unnecessary personal information. The team should be able to see error rate, job delay, feature usage and support impact by customer or tier.
This also helps with economics. AWS recommends measuring tenant activity and cost because SaaS pricing and infrastructure cost need to make sense together. A customer whose workload costs more than its subscription is a commercial signal, not merely a hosting problem.
Monitoring should feed an operating routine. Someone needs to own alerts, review recurring faults and decide whether a manual recovery step should become an automated control.
10
Treat privacy and security as product work
The ICO's current guidance says data protection should be considered at the design stage and throughout the product lifecycle. It also requires organisations to limit personal information to what is necessary for the stated purpose and to control who can access it.
For a SaaS product, that affects forms, roles, exports, analytics, logs, support tools, backups, retention and account closure. It is difficult to bolt these decisions on after customer data has spread across the platform.
A development service should help the business map what personal information it uses, why it is needed, who should see it and when it should be removed. The business remains responsible for its legal obligations. The software should make the chosen controls practical and visible.
Security also includes mundane ownership. The customer buying the development service should know who controls the source code repository, cloud account, domains, production credentials, email provider, payment account and analytics. Strong application code does not compensate for a critical account registered to a supplier's personal email address.
11
Agree what happens after launch
Launch is when a SaaS product begins collecting evidence, not when development ends.
Real customers will reveal confusing language, awkward onboarding, edge cases and support work that no workshop predicted. The team needs a route for turning that evidence into product decisions without accepting every request as a bespoke feature.
The post-launch agreement should cover monitoring and incident response, security updates, backup and recovery checks, deployment, product analytics, billing queries, prioritisation, documentation and ownership.
AWS recommends repeatable onboarding and warns against one-off versions of the product for individual customers. Configuration and feature controls can support different tiers or staged releases, but hundreds of special switches create their own maintenance problem.
The useful discipline is to separate a genuine product capability from a request that belongs in one customer's private fork.
12
Questions to ask a SaaS development partner
Before choosing a supplier, ask them to walk through the complete life of one customer rather than only showing interface work.
How is the first account created? How are users linked to the correct tenant? What prevents data crossing that boundary? How do subscription changes affect permissions? How does the team diagnose one customer's fault? What is monitored? How are backups restored? What can the customer export? Who owns every account and repository if the development relationship ends?
Good answers do not need to be elaborate. Early products benefit from restraint. What matters is that the choices are explicit, proportionate and testable.
A credible SaaS development service should be comfortable discussing where not to build. It should distinguish a launch requirement from a later optimisation, and a proven customer need from an architectural fashion.
13
Buy an operating service, not a collection of screens
The visible product matters. Customers need clear screens, a useful workflow and a reason to return. But SaaS value also depends on what happens around those screens: onboarding, isolation, billing, permissions, monitoring, support, deployment and exit.
The right development partner does not need to make the first version enormous. It needs to make the boundaries clear and build the smallest version that can be sold, supported and improved without relying on invisible manual work.
If you are scoping a SaaS product, start by mapping one customer's full journey from invitation to account closure. That exercise usually reveals whether the proposal describes a genuine service or only the interface people will see.
Useful questions
Before the next software decision, ask:
- Is the technical direction clearly linked to a business goal?
- Do the people building the system understand the commercial priority?
- Are risk, cost, security and delivery trade-offs visible early enough?
- Can the current platform support the next stage of growth?
