Multi-tenancy, billing and permissions settled before the first line rather than discovered in month four — because those three are cheap to get right early and brutal to change once you have paying customers. Deployed to your accounts, yours outright.
Multi-tenancy, the billing model, and the permission system are the three things that are cheap to get right at the start and brutal to change once you have paying customers. We settle them during scoping, in writing, rather than discovering them in month four.
Upgrades mid-cycle, downgrades, failed payments, trials, refunds, annual plans, tax. Subscription billing is where SaaS builds quietly overrun, because the happy path is a day and the other paths are the rest of the month. It is scoped explicitly, not assumed.
Conventional structure, documented repositories, no clever abstractions that only make sense to the person who wrote them. The point at which you hire is the point at which build quality either pays off or bills you.
The right column is not a limitation — it is the list of things that reliably get built too early, then rebuilt once real customers show what they actually needed.
The product, and the parts that are expensive to add later.
Recommended for later — included from the start whenever you want them.
Need any of these on day one? They go in. If you already have an enterprise customer asking for SSO, or a reseller waiting on white-labelling, that changes the answer entirely — this list is a default for products without those commitments yet, not a restriction on what we will build.
In our experience it is almost never the technology. Four things account for most of the damage, and all four are decided before any code is written — which is why scoping is a conversation rather than a form.
A data model that cannot bend
The most expensive thing to change and the least visible when it is wrong. It gets designed against how the business actually works, not the demo.
Billing treated as an afterthought
The happy path is a day. Proration, dunning, downgrades and tax are the rest of the month, and they touch the data model.
Building for imagined scale
Distributed architecture for a product with no users costs months and buys nothing. Scale when there is something to scale.
Shipping before anyone wants it
The commonest and least technical failure. If you have not sold it to anyone yet, build less than you think.
Frontend web platform for Nullzec, an enterprise browser-isolation company. WizCodes built the client-facing web application and dashboard UI — the interface through which the product is configured and monitored.
Full-stack web platform built for a Spanish client with custom business logic and a responsive, performant frontend.
B2B solar vendor discovery and procurement marketplace for the Indian market. Multi-vendor listings, quote requests, and vendor profile pages.
Almost always yes, and it is much less work up front than the retrofit. Multi-tenancy means every row of data belongs to a tenant and no query can accidentally cross that boundary. Building it in from day one costs a modest amount of extra design in week one; adding it later means touching every table, every query and every endpoint in a system that already has customers in it, and getting one wrong is a data leak between clients. The reasonable exception is a single-tenant product genuinely deployed per customer, which is a real model for enterprise software but rare for anything self-serve. What you can defer safely is the sophistication — a clean tenant boundary with database row-level security is not the same as a full organisation hierarchy with nested teams, and only the boundary is urgent.
Through a payment provider, usually Stripe, with your account rather than ours — subscriptions, invoices and card data stay on their side, which keeps you out of PCI scope. The build is not the checkout; it is everything the checkout implies. What happens when someone upgrades halfway through a month, and how proration is presented. What a downgrade does to data that exceeds the new plan's limits. What the product does across a failed payment, the retry window, and eventual cancellation, and what the customer sees at each stage. Whether trials need a card. How annual and monthly coexist. These get decided during scoping because they are product decisions with revenue consequences, not technical details, and they are the part of a SaaS build that most reliably takes longer than expected.
Worth separating two things that get conflated. A formal SOC 2 report is an audit of your company's processes performed by an accredited firm — we are not auditors and cannot grant it. What we can do is build so that the audit is straightforward rather than a rebuild: encryption in transit and at rest, real access control, audit logging of sensitive actions, sensible secret management, environment separation, and infrastructure-as-code so your controls are demonstrable rather than described. Most of that is good practice we would apply anyway. Say early if enterprise buyers are on your roadmap, because a few decisions — audit logging, tenant isolation strategy, data residency — are far cheaper designed in than retrofitted under time pressure during a deal.
The honest answer is that the foundations should last and some layers will be replaced, and the useful skill is knowing which is which. A sound relational data model, clean tenant isolation and a conventional architecture carry a product a long way — considerably further than most founders are told, since the bottleneck for the overwhelming majority of SaaS products is finding customers rather than serving them. What does get revisited is anything sized for a guess: a background job that was fine at ten customers and not at ten thousand, a query without the index it now needs, a report generated live that should be precomputed. Those are incremental fixes, not rewrites. We deliberately do not build for imagined scale, because premature distributed architecture is a far more common cause of failure than an overloaded database.
Yes, and the first deliverable is an honest assessment rather than a proposal. We read the codebase, the data model, the deployment setup and the billing integration, then tell you what is solid, what is fragile, and what is genuinely cheaper to replace than to keep. That judgement gets held to a high bar in the direction of replacement, because recommending a rewrite is the profitable answer and therefore the one to be most sceptical of. Typical work is untangling a data model that was never multi-tenant, fixing billing edge cases that are leaking revenue, adding the test coverage that makes changes safe, and getting deployment reproducible. You get the assessment before committing to build work.
Choosing the database underneath it is covered in choosing a database for a SaaS product. If you are at the very start, MVP development is the better entry point.