"Build it so it scales" is usually interpreted as an infrastructure instruction, and infrastructure is rarely what stops a SaaS product growing. The things that hurt later are structural decisions that are cheap on day one and expensive on day four hundred.
Decide tenancy before you write the first model
How a customer's data is separated from every other customer's data is the decision with the longest reach. It affects every query, every migration, every export, every access check, and every answer you give in a security review.
You do not need the sophisticated option immediately. You do need to have chosen deliberately, because retrofitting a tenant boundary onto a schema that assumed one customer is one of the most expensive pieces of work in software.
Model roles as permissions, not as job titles
Early products tend to hard-code a small set of roles (admin, user, maybe manager) with behaviour scattered through the code as checks against a role name. It works until the first customer wants someone who can approve but not delete, or view everything but edit only their own team's records.
Naming the individual capabilities and grouping them into roles is barely more work at the start, and it means the answer to that request is configuration rather than a refactor. In the compliance platform we worked on, this mattered enormously: corporate users, external professionals, administrators, and super administrators each needed genuinely different authority over the same records.
- Name capabilities, not people: approve_filing, export_document, manage_billing
- Roles are named bundles of capabilities
- Check capabilities in code, never role names
- Assume a customer will eventually want a role you did not predict
Treat billing as product logic
Subscriptions, trials, seat counts, usage limits, and plan changes are commonly deferred as "just Stripe." The payment provider is the easy half. The hard half is what your product does when a trial ends mid-workflow, when a card fails, when a customer downgrades below the number of seats they are using, or when usage runs out halfway through a job.
Products that handle this well usually decided early where balance and entitlement checks happen. In the campaign product we built, credits were held before a send rather than charged after it, precisely so a campaign could not half-deliver and leave the ledger disagreeing with reality.
What genuinely can wait
Plenty can be deferred without regret, and being clear about that is what makes an early product shippable.
- Microservices, a well-organized single application will take you a long way
- Multi-region deployment and read replicas
- A custom design system
- Self-serve onboarding, while you still onboard customers by hand
- Automated everything, some operations are cheaper done manually for the first fifty customers
The useful test
For any decision you are considering deferring, ask what it would cost to change once you have real customers with real data. Tenancy, permissions, and billing all score badly on that test, which is why they are worth thinking about first. Almost everything else scores well, which is why it can wait.