Insights · 5 min read
Building a SaaS is less about screens and more about tenancy, billing, and onboarding. Where the engineering effort really goes and what to build vs buy.
By GGP Editorial
Building a SaaS product is different from building a website or an internal tool. The product is the same for every customer, but the data, the billing, and the onboarding have to feel separate for each one. Most of the engineering effort in a SaaS goes into parts the user never sees: tenancy, permissions, billing, and upgrade paths. The screens are the easy part.
Tenancy is the question of how you store each customer's data. You can put every customer in one shared database with a tenant id on each row, or give each customer their own database or schema. The choice shapes your scaling, your backups, and how easy it is to onboard a big enterprise client later.
| Model | Good for | Watch out for |
|---|---|---|
| Shared database | Early stage, many small accounts | One noisy tenant can slow everyone |
| Schema per tenant | Mid-size, needs data isolation | Migration and upgrade work |
| Database per tenant | Enterprise, compliance-heavy | Cost and ops overhead |
There is no right answer for everyone. Start with a shared database and a tenant id on every row, and design your queries so you can split tenants out later without a rewrite. The rewrite is what hurts, not the initial choice.
Founders treat billing as plumbing they will wire up at the end. In a SaaS, billing touches the customer from day one: trial, plan limits, upgrade, downgrade, invoice, dunning. Get the subscription logic right and it drives revenue. Get it wrong and support spends its days explaining charges.
The parts that catch people: proration when someone upgrades mid-cycle, what happens to data when a plan is downgraded or cancelled, and dunning when a card fails. Each of these is a small feature on its own. A payment gateway with good subscription support, or a billing layer on top of it, saves a lot of custom code. The same idempotency and webhook rules from payment integration apply here, so it pays to get that foundation right.
How you charge is also worth deciding on paper first. Per-seat pricing is easy to sell but caps growth when one account wants to add twenty users. Usage-based pricing matches value to cost but makes the bill harder to predict for customers. There is no one winner, but the pricing model changes the data you have to meter from day one, so pick it before you build the metering.
A SaaS customer decides in the first few sessions whether the product is for them. That means the signup flow, the first data import, and the moment they see value have to be designed, not left to default forms. A product that is powerful but takes an hour to set up will leak users in that first hour. Spend real design time on the first run: what does the user see before they add any data, and how fast can you get them to a working result.
Churn is the number that tells you whether the product works, and you can only read it if you instrument from the start. Log the signup source, the activation event, and the last login per account. Without that you are flying blind about which customers stay and which quietly stop paying. A rule we repeat to founders: fix the moment a user first gets value before you add any new feature, because a feature nobody reaches does nothing for retention.
A SaaS has a long list of non-product needs: auth, payments, email, feature flags, usage metering, analytics, support tickets. Building all of them yourself is a trap. Pick boring, proven services for the parts that are not your differentiator, and spend your engineers on the thing customers actually pay for. The discipline is knowing which is which. Ship the smallest version one customer would pay for, then expand. The second customer is cheaper to win than the first, and the third cheaper still.
We have built financial systems, ERP modules, and trading platforms, and they share a lot of DNA with SaaS: multi-tenant data, permission models, recurring billing, and audit trails. That background means we do not discover these requirements halfway through a build.
We are a China-based team that has shipped for customers in Brazil, South Africa, Singapore, and the United States. We run overlap hours for calls, keep a dedicated group for daily updates, and work in English or Portuguese. If you are a founder planning a SaaS and are not sure whether to build or buy a given component, we would rather spend an hour mapping it with you than see you pay for the wrong thing.
Tell us what you are building and where you are today. We typically reply within 24 hours.
