Building a software product, not just a project

What building a SaaS platform actually requires

Founders usually arrive describing the features their product will have. Those features are typically the smallest part of the work. What consumes the schedule is everything surrounding them, namely accounts and organisations, invitations, roles and permissions, onboarding for people who have never seen the product, subscription handling, notification infrastructure, usage reporting, administrative tools for your own team and the monitoring that tells you something is wrong before your customers do.

The second surprise is that a product must be built for people you will never meet. Internal software can rely on training and a colleague at the next desk. A product cannot. If a new user cannot work out what to do in the first two minutes, they leave and you never learn why. That reality drives us to design the empty state, the first run experience and the moment somebody invites a colleague with far more care than a typical business system would need.

The third is that a product accumulates data far faster than anyone plans for. A table that looks fine with a thousand rows behaves very differently at ten million, and the point where it degrades is usually the point where the business is growing and least wants a distraction. We design the data model and the indexes with that trajectory in mind from the start.

Multiple tenants without leaking between them

Almost every SaaS platform serves many separate organisations from one system, and the single most damaging failure available is showing one customer another customer data. We enforce separation at the database query level, not merely by filtering in the interface, and we test it deliberately by attempting to reach records that should be invisible.

Alongside separation sits the permission model within each organisation. An administrator can invite and remove people. A manager can see everything in their branch. A regular user sees only their own work. An external collaborator sees one project and nothing else. Getting this structure right early is essential, because retrofitting a permission model into a running product is one of the most disruptive changes possible.

Subscriptions, trials and the billing reality

Billing is where many products lose money quietly. Trials that never convert because nobody followed up. Accounts that keep working after a card fails. Upgrades that do not take effect until somebody notices. Refunds handled by hand in a spreadsheet. We build the subscription logic properly, integrating with a payment provider so cards, renewals, failures, upgrades, downgrades and cancellations all behave predictably.

Equally important is what happens at the edges. What does a customer see when their trial ends? Can they export their data if they leave, and how quickly? What happens to their records if they come back three months later? These questions have real commercial consequences and they deserve deliberate answers rather than whatever the code happens to do.

Starting small on purpose

The most common way a new product fails is by trying to launch complete. Eighteen months of building without a paying user produces something confidently wrong, and the money runs out before the corrections can be made. We push hard for a first version that solves one problem properly for one clear group of users, released early enough that reality can still shape it.

That does not mean building carelessly. The foundation, meaning the data model, the tenancy, the permission structure and the deployment, is built properly from day one because those are expensive to change later. The feature surface is what stays small. That combination gives you something you can grow rather than something you must replace.