SaaS product build: what you need beyond the core features

An internal system trusts everyone who logs in: one company, one set of masters, and one admin who fixes things straight in the database when a record goes wrong. It ends when company two signs up.

Look at what your current tool assumes: a single tax setup, a hard-coded company name on invoices, and one shared item list. Each of those assumptions is a doorway through which customer A could read customer B’s invoices, stock or price list, and nobody would notice until a complaint arrived.

Your customers’ favourite features are usually built already. The work ahead is the scaffolding around them, which has its own build order, so plan it before the first paying sale.

Every table that holds customer data needs a tenant key, and every query, report and export must filter on it without exception. Decide now whether tenants share one database with a tenant_id column, get a schema each, or get a database each, and record the choice before building.

The choice shapes backups, reporting and the cost of a noisy customer who runs heavy exports at month end and slows everyone else down. A shared schema is cheapest to run. A database per tenant makes restoring one customer’s data from last Tuesday much simpler, though you pay for it with more servers to patch and back up.

Files, search indexes, caches, queued emails and background jobs all need the same tenant key, or a job started for one customer can read another’s. Teams remember the tables. They forget the uploads folder. That is the leak.

A subscription needs its own catalogue: plans, add-ons, seat counts, usage meters, trial length, and exactly what happens to the account when a trial ends. Store these as data. Scattering if-statements through the code means a developer must ship a release for every price change, every new add-on and every special deal the sales team agrees.

Tie feature flags to the plan. Sales can then change a package, switch a module on for one customer and test a new bundle, all without waiting for a developer to release anything. Limits need a friendly failure. Show a warning at the threshold, then a block with an upgrade path at the cap, so the customer never meets a raw error page mid-task.

Self-service signup comes with it. A visitor enters an email, verifies it, names the workspace and lands in an account already seeded with sample masters and a demo company within a minute. Hand setup costs you on every sale.

Recurring billing is more than a gateway button. You need invoices with the customer’s tax details, proration when someone upgrades mid-cycle, credit notes, and a retry schedule when a card fails.

Dunning is the retry schedule plus the messages around it, for example a soft email on day one, a warning on day five and read-only access on day twelve. Leave the data intact. A late payer should be able to pay the invoice and walk straight back into a working account, with every record exactly as they left it.

Test the ugly cases before launch: expired cards, a downgrade after a refund, a customer who pays twice, and a webhook that arrives a day late. Finance meets them all in month one.

Support must see what a customer sees. An operator console lets staff search tenants, view plan and usage, reset a user, extend a trial and impersonate a login with an audit trail. Without it, engineers run queries against production.

Log who looked at what and why. Customers in regulated trades such as pharmaceutical distribution or food processing will ask to see that audit log during supplier due diligence. Keep it ready.

Finish with the exit. Customers will want a full export of their invoices, items and users, and some will demand deletion with a written confirmation that every copy is gone. Build the export job and the deletion job now, then run both on a test tenant this month and keep the result as proof for the first security review.