What does a SaaS product need before its first paying customer?

Before a SaaS product takes its first payment, it needs six things beyond the core feature: customers kept separate from each other, a dependable way to charge them, correct invoices, a plan for failed payments, a way to support users, and basic security. Most of this is invisible when it works, and very visible when it does not.

What is multi-tenancy and why does it matter early?

In a multi-tenant product, many customers share one application, and each sees only their own data. The decision shapes your database, your permissions and your hosting costs, and it is expensive to change later.

There are three common approaches. All customers share one database, with every record tagged by tenant. Each customer gets a separate schema inside one database. Or each customer gets a separate database. The first is cheapest and simplest to run. The last gives the strongest separation, which some larger customers ask for.

For most early products, a shared database with strict tenant checks on every query is a sensible start. What matters is that the check cannot be forgotten: put it in one place in the code, and test that one tenant can never read another's records.

Also decide early how users relate to tenants. Can one person belong to two companies? Can an admin invite colleagues? These questions look small and cause large rewrites when ignored.

How should you handle billing and subscriptions?

Start with what you charge for: per user, per usage, per feature tier, or a flat plan. Keep it simple until you have customers who tell you what they value.

Then choose how you collect money. Options include a payment gateway with built-in subscriptions, a billing platform on top of a gateway, or manual invoicing for the first handful of customers. Manual invoicing is not embarrassing at the start. It lets you learn what customers want before you build plans, trials and upgrades into code.

When you do build it, plan for these cases: free trials, upgrades and downgrades mid-month, cancellations, refunds, and customers who need an annual invoice with a purchase order. Each one is a rule in your system.

How do GST and VAT affect your invoices?

If you sell to Indian businesses, your invoices need to meet GST requirements, including the correct GSTIN details, tax breakdown and place of supply. If you sell to businesses in the UAE, VAT applies under the Federal Tax Authority's rules, and invoices have their own required fields. Confirm the current requirements with your chartered accountant, because rules and thresholds change.

Build invoice generation as a feature of the product, not a spreadsheet job. Store the billing name, tax number and address for each tenant, and keep every invoice you issue as a fixed record that cannot be silently edited.

What happens when a payment fails?

It will, regularly. Cards expire, UPI mandates are revoked, banks decline. A failed-payment routine should do four things: retry automatically on a sensible schedule, email or message the customer each time, give a grace period before access changes, and let the customer fix the payment themselves without contacting you.

For Indian customers on recurring card payments, the Reserve Bank of India's e-mandate framework governs how recurring charges are authorised and notified. Your payment provider handles most of the mechanics, but your product has to support the flows they require. See our note on choosing between Razorpay and Stripe for how that plays out when you sell abroad.

How will users get help?

Decide this before launch. At minimum you need one inbox or WhatsApp number the team watches, a short help page covering the first five questions, and a way to see what a user was doing when something broke. That last item is why error logging matters.

Add an in-app way to report a problem, and note who owns replies. A small product loses customers far faster to silence than to missing features.

What security does a first version need?

Not everything, but the basics are non-negotiable:

• Passwords stored properly, with a reset flow, and multi-factor sign-in for admins.
• Encrypted connections everywhere, and secrets kept out of code.
• Role checks on every action, not just on the screens.
• Daily backups, and a restore you have actually tried.
• A log of important actions, such as logins and data exports.
• A privacy notice and consent wherever you collect personal data, in line with the Digital Personal Data Protection Act, 2023.

Certifications such as ISO 27001 or SOC 2 can wait until a customer asks, though building the habits early makes them easier. Where we help with these, we implement the controls and work with accredited audit partners for the certificate itself. If you serve Gulf customers, check the data rules of the country involved, for example the UAE's Federal Decree-Law No. 45 of 2021 on personal data.

What can you leave until later?

Single sign-on, complex roles, white-labelling, an API for customers, usage analytics dashboards and multiple currencies can usually wait, unless your first customers specifically require them. For a fuller list of what to defer, see how much of an MVP to build first.

A short checklist before you take payment

• Tenant separation is built in and tested.
• You can charge, refund and invoice correctly, with GST or VAT handled.
• Failed payments trigger retries and messages.
• Someone owns support, and there is a place to see errors.
• Backups run and a restore has been tried.
• Privacy notice and terms are live.

We cover this under SaaS development and the wider Product Development pillar. This is the kind of work we do for founders, often beginning with a Product Discovery Sprint to settle the scope. To discuss yours, Let's Talk.