SaaS App Development: The Architecture Decisions You Cannot Undo

Building software as a service differs from building an application in four specific ways: many customers share one system, customers have internal structure of their own, money arrives on a recurring schedule, and you operate the thing forever. Each of those introduces decisions that are cheap at the start and extremely expensive later.

‍

This is a description of those decisions, in the order they should be made.

Decision one: the tenancy model

Multi-tenancy means many customer organisations sharing one system with their data properly isolated. There are three common approaches and the choice affects everything above it.

Shared database with a tenant identifier on every row. The default for most SaaS products. Cheapest to operate, simplest to deploy, and it puts the entire burden of isolation on your query layer. Every query must be scoped, and a single missing condition is a cross-customer data leak.

Shared database with schema separation per tenant. Stronger isolation, more operational complexity, and migrations become a per-tenant operation.

Database or instance per tenant. Strongest isolation, highest cost, and sometimes the only acceptable answer for enterprise or regulated customers with data residency requirements.

Most products should start with the first and enforce isolation structurally rather than by developer discipline. Database row-level security, a query layer that requires a tenant context, or a repository pattern that cannot be called without one are all better than a code review convention. The failure mode here is not gradual, it is a single incident.

The decision that must be made now rather than later is whether a user can belong to more than one organisation. Retrofitting that is one of the most disruptive migrations in SaaS work, and a great many products discover the need within a year.

Decision two: the permission model

Customers have hierarchies, and your permission model has to express them without becoming unmanageable.

A single role field works for two roles and breaks at five. What works durably is roles as data rather than as an enum, permissions attached to roles rather than to users directly, checks performed server-side in the query, and an audit trail of permission changes.

Two additional needs arrive predictably. Enterprise customers will ask for custom roles, which means your model needs to accommodate roles you did not define. And your own support team will need a way to act on a customer's behalf, which is a real feature with real risk and should be built deliberately with logging rather than improvised through shared credentials.

Decision three: billing that runs without you

Subscription billing is more than a payment form. The states a subscription can occupy, trialing, active, past due, paused, cancelled but active until period end, cancelled, are a state machine, and your product's feature access has to follow it.

The specific pieces that get missed: proration when a customer changes plan mid-period, dunning behaviour when a card fails including retry schedule and notifications, self-serve cancellation without contacting you, invoice access and receipt delivery, usage metering if any pricing is consumption-based, and tax handling, which for cross-border sales is a genuine compliance obligation rather than a rounding concern.

Use a billing provider rather than building this. The engineering work is the integration and the state synchronisation, and even that is substantial: two to four weeks for a straightforward subscription model and considerably more for usage-based or hybrid pricing.

The number worth checking in any SaaS proposal: how many weeks are allocated to billing. A single week means a checkout form was priced and the subscription lifecycle was not, and the difference will surface the first time a customer downgrades mid-month.

Decision four: what enterprise buyers will require later

‍

‍

You do not need these at launch, and designing so they are possible costs almost nothing while retrofitting them costs a great deal.

Single sign-on through SAML or OIDC, which is a near-universal requirement above a certain deal size. Audit logs that customers themselves can read, distinct from your internal logging. Data export in a usable format. Configurable data retention. Role customisation. And a security questionnaire response supported by real controls, which arrives before the contract rather than after.

The practical guidance is to keep identity, permissions, and audit logging as clean, well-separated components rather than as logic distributed through the application. Every one of the requirements above lands on one of those three.

Choosing a partner for SaaS work

General app development competence does not imply SaaS experience, and five questions establish the difference.

How do you enforce tenant isolation? The strong answer is structural, meaning row-level security, a query layer that cannot execute without a tenant context, or an equivalent mechanism. The weak answer is that developers remember to include the condition, which is a convention rather than a control.

How do you model roles and permissions? Roles as data with permissions attached, checked server-side. Anything involving a single role column will fail at the fifth role.

How many weeks are allocated to billing, and what does that cover? Proration, dunning, plan changes, and self-serve cancellation, or a checkout form. The answer tells you whether the subscription lifecycle was priced.

What internal tooling is included? If the answer is none, your engineering budget will be consumed by support requests within a month of launch.

What would you build now so single sign-on and audit logs are addable later? A partner who has taken a product through enterprise procurement will answer this immediately.

Bolder Apps builds web front ends in React with Ant Design or Material, backends in Laravel, Yii2, and Node.js, and prices project work fixed-scope rather than hourly with projects starting around $30,000. What is worth requesting from any firm is a proposal that lists tenancy, permissions, billing, and internal tooling as separately priced items, because those four are where SaaS builds diverge and where an underspecified quote hides.

Phasing a SaaS build

SaaS products are rarely well served by a single large first release, because the enterprise feature list is effectively unbounded and the market feedback arrives only after launch.

Phase one: one workflow, organisation-level accounts with two roles, subscription billing, internal admin view, analytics. Ten to sixteen weeks. This is a product you can sell.

Phase two: whatever your first twenty customers actually asked for, which will not be what you planned. Usually reporting, one integration, and a second workflow.

Phase three: enterprise readiness. Single sign-on, customer-facing audit logs, data export, role customisation, and the security documentation procurement will request. Built when a deal requires it rather than in anticipation.

The discipline that makes this work is architectural rather than commercial: keep identity, permissions, and audit logging clean and separable in phase one, and phase three becomes a contained project rather than a rewrite.

The operational tooling you will need in month one

Every SaaS product needs internal tooling, and it is the most reliably omitted item in a first build.

‍

‍

Read access to accounts, their subscription state, and recent activity. The ability to adjust a subscription, issue a credit, or extend a trial without a database query. Support impersonation with consent and logging. A view of failed payments and failed jobs. And basic health monitoring with alerts that reach a human.

Without these, every customer question and every billing exception consumes engineering time, permanently. Budget 15 to 20 percent of the build for internal tooling and treat it as customer-facing, because it determines the quality of your support.

Cost and timeline

Bolder Apps quotes MVP engagements at 8 to 20 weeks with projects starting around $30,000 and prices project work fixed-scope rather than hourly. The reason fixed-scope suits SaaS first versions specifically is that the enterprise feature list is effectively infinite and always available as a distraction, and a priced scope makes each addition a decision rather than a drift.

Ongoing cost, which is the part SaaS founders underestimate

SaaS is an operating commitment rather than a delivered project. Three lines run permanently.

Infrastructure, $150 to $2,500 per month at early scale, growing with usage rather than with customer count. Third-party services, billing, email, monitoring, search, analytics, $300 to $1,500 per month. And engineering, which for a SaaS product in its first two years is not maintenance but continuous development, realistically 25 to 35 percent of build cost annually..

Founders who raise on early traction with no engineering budget for the following two quarters are a recognisable pattern. Reserve it in advance.

Where AI fits in a SaaS product

The strongest applications are the ones that remove a repetitive task inside the workflow your customers already perform: summarising records, drafting content they currently write, extracting structured data from what they upload, categorising or routing items.

Two SaaS-specific considerations. Unlike every other feature you ship, this one has a marginal cost per use, which means unlimited access on a low-priced tier is a structural problem rather than a generosity decision. And your enterprise customers will ask what happens to their data, so provider agreements and retention behaviour become a sales question rather than only a technical one.

Frequently asked questions

Should we build multi-tenancy from the start? Yes. Building single-tenant and adding multi-tenancy later means touching every query and migrating live data. Even if your first three customers are handled manually, the tenant identifier belongs in the schema from day one.

Do we need single sign-on at launch? Almost never, and you should design so it is addable. Keep authentication as a separable component rather than woven through the application, and adding SAML or OIDC later becomes a contained project rather than a refactor.

How should we handle a customer who wants their data in their own region? This is a tenancy and infrastructure question, and it is worth knowing before you promise anything. Answering it well generally requires either a per-tenant deployment option or region-aware infrastructure, both of which are considerably easier to design for than to retrofit.

What is the most expensive mistake in SaaS architecture? A permission model that cannot express what customers need, followed by an assumption that a user belongs to exactly one organisation. Both require broad migrations and both are avoidable with an hour of thought during discovery.

Can a SaaS MVP be built without billing? If willingness to pay is not part of what you are testing, yes, and you can invoice your first customers manually. If revenue is the hypothesis, billing is the experiment and cannot be deferred. Manual invoicing stops scaling somewhere around ten to twenty customers.

Sources

• Stripe Billing documentation on subscription states, proration, and dunning, stripe.com/docs/billing
• PostgreSQL documentation on row-level security
• Auth0 and Okta documentation on multi-tenant identity and SAML integration
• SOC 2 Trust Services Criteria, AICPA
• NIST Special Publication 800-53, access control and audit families
• Amazon Web Services and Google Cloud published pricing calculators