How do you keep one customer’s data away from another’s?
By deciding the isolation model before the first table is created, because it is the one thing that is genuinely painful to change later. Whether tenants share a database with enforced row-level separation or get their own depends on your customers and what they will be asked in security reviews. Whichever it is, the rule is enforced in one place rather than remembered in every query.
Should we build billing ourselves?
No. Use an established payments provider and let it own cards, invoices, tax and the retry logic for failed payments. What still belongs to you is the part nobody else can do: what a plan includes, what happens on the day a subscription lapses, and how an upgrade halfway through a month is counted. That logic is where subscription products actually break, and it is where we spend the time.
How do you ship updates without breaking existing customers?
Changes go out behind flags so a feature can be turned on for one account before all of them, and the database changes are written to work with both the old and the new code for as long as both are running. That is what makes a rollback a decision rather than an emergency, and it is what lets a SaaS product be updated on a Tuesday afternoon instead of at midnight.
What do enterprise customers ask for that startups do not?
Single sign-on, an audit log they can export, a data processing agreement, a defined uptime commitment and somewhere to point their own security questionnaire. None of these are hard if they are anticipated, and all of them are expensive to retrofit into a product that assumed every user signs up with an email address and a password.
How long before we can put it in front of paying customers?
Sooner than a full product, and the useful question is which parts cannot be faked. Sign-up, tenant isolation and taking money have to be real, because those are the ones that damage trust or leak data if they are improvised. A great deal else can be deliberately manual at the start: onboarding done by a person, reports assembled by hand, an admin action performed by your team rather than self-served. Charging real money from the first cohort tells you more than any amount of research, and doing the unscalable parts by hand tells you exactly which ones are worth automating.
What does it cost to run, and how do we know what to charge?
You should be able to see what a single account costs you to serve, and most products cannot, which is why so much SaaS pricing is guesswork with a confident face. We instrument usage and cost per account from the start: storage, compute, third-party API calls, and the support load, which is the expense that never appears in an infrastructure bill and frequently dominates. That is what lets you notice the customer paying the smallest plan while generating a third of your costs. Collected from day one it is a report; reconstructed in year two it is an archaeology project.
Who owns the code and the customer data?
You own both, and for a SaaS product the second half of that matters more than people assume. The code sits in your repository and the cloud accounts are in your company's name with your billing details. More importantly, you should be able to get every customer's data out in a usable form, on demand, without our involvement: because your own customers will eventually ask you for exactly that, and because a business whose data is only reachable through its supplier has a dependency it cannot price. Export is built as a product feature rather than as a favour someone performs with a database client.
What happens when a customer wants their own region or their own instance?
It is a business decision with a large engineering bill attached, and it is worth pricing as one rather than agreeing to in a sales meeting. A single deployment serving everyone is dramatically cheaper to operate than several, and each additional region or dedicated instance multiplies deploys, migrations, monitoring and the number of places an incident can happen. Sometimes the contract justifies it. What makes it survivable is having anticipated it in the isolation model rather than promising it to a large customer and then discovering the architecture assumed one deployment forever.
