Eight things new SaaS developers need to know before building

Executive overview

SaaS is not like client projects or websites — the data models, user flows, and business dynamics are fundamentally different. Getting these wrong early costs enormous time later, when you have thousands of customers and can't easily make structural changes.

Eight principles from experienced SaaS founders cover the technical, product, and business mistakes most new builders make.

Marketing and customer communication matter more than product features — most developers learn this too late.

Continuous delivery over big feature branches

• Break projects into the smallest shippable units and deploy to production early.
• Long-running feature branches accumulate merge conflicts and kill momentum.
• Use feature flags for user-facing work that isn't ready to expose.
• Small changes are easier to reason about and often reveal the feature is usable sooner than expected.

Data model and account structure

• Think through your users, teams, organisations, accounts, and billing model before writing much code.
• With SaaS, restructuring a data model at 1,000+ customers is expensive and risky.
• Favour one-to-many relationships by default — assuming one-to-one is the most common mistake.
• SaaS data models need more flexibility than traditional software from the start.

Onboarding is not an afterthought

• Design the user journey from day one of architecting your flows.
• Assume new users know almost nothing about the product.
• In-app onboarding: guide users to the activation moment (e.g. connecting a calendar) before they reach the main UI.
• Email sequences: welcome, educate, and send follow-up nudges on subsequent days to pull users back in.

Choose who you listen to carefully

• Only take advice from people who have built what you want to build, at the scale you want to reach.
• Many people online embellish experience they don't have — their advice can actively mislead you.
• A founder who scaled to $20k MRR gives different (often wrong) advice for a $500k MRR target.

Choose a boring tech stack

• Customers don't care what technology you use.
• Adopting unfamiliar or experimental tools slows delivery and delays validation.
• Technologies that don't catch on leave you with a codebase few people know how to work with.
• Stick to battle-tested frameworks and let yourself focus on delivering customer value.

Learn the basic SaaS acronyms and metrics

• MRR, ARR, ACV, LTV, MVP, churn — these terms are used constantly and misunderstanding them costs money.
• Knowing what MVP actually means would have saved many founders significant time and money.
• Start with the basics: revenue, profit, recurring revenue, then build up to expansion revenue and net negative churn.

Write tests for the core functionality

• Don't test every nook and cranny, but don't write zero tests either.
• Prioritise functional or system tests that cover entire flows over granular unit tests.
• At minimum, test the pieces where a bug would be most damaging.
• Technical debt in an untested codebase becomes critical exactly when you start gaining traction.

Marketing and talking to customers are not optional

• "Build it and they will come" does not apply to SaaS — no one succeeds without marketing.
• Talk to potential customers, not just friends.
• The endless feature-building loop is easy to fall into; marketing is the blood of a SaaS business.
• Every successful SaaS founder was doing both: marketing and direct customer communication.