The First Ten Decisions Before Writing a Line of Code
What to settle before touching the editor — the decisions that are expensive to reverse later.
Article illustration — 1600×700px
Not every decision in a SaaS build deserves the same amount of deliberation. Some are cheap to change later — button color, copy, even the framework in some cases. Others are expensive to reverse once real users and real data depend on them. This is a list of the second kind.
The ten decisions
- Who the first version is for — specifically, not broadly. A product for “everyone” launches to no one.
- What data model represents the core object of the product — changing this after real data exists is one of the most expensive migrations in software.
- Multi-tenant or single-tenant architecture — this shapes the database, auth, and billing from day one.
- Authentication approach — build it, or use a managed provider. Rebuilding auth later means migrating every existing user.
- Pricing model shape — seat-based, usage-based, flat — even before exact numbers are set, because it affects what gets tracked from day one.
- What gets logged and tracked from the first user, not added retroactively once the question “why did they churn” comes up with no data to answer it.
- Hosting and deployment approach — not because it’s hard to change, but because migrating it later costs focus better spent on the product.
- How support requests get handled — even a shared inbox is a decision; deciding nothing means requests get lost.
- What “done” means for version one, written down, before building starts — not discovered by consensus three weeks in.
- Who has final say when two reasonable opinions disagree — decided once, in advance, not re-litigated on every disagreement.
The reversibility test
For any decision, ask: if this turns out wrong in six months, does fixing it mean a small code change, or a migration that touches every existing user and every row of data? The second kind deserves the deliberation up front.
What this isn’t
This isn’t a call to overthink everything before starting. Most decisions in a SaaS build are genuinely cheap to change and should be made fast, by instinct, and revisited later if needed. The ten above are the exceptions — worth the extra hour of thought precisely because they’re not cheap to undo.
The takeaway
Speed in early-stage SaaS building comes from moving fast on the decisions that are cheap to reverse, and moving deliberately on the ones that aren’t. Confusing the two — agonizing over button copy while rushing the data model — is one of the most common and most avoidable mistakes in a first build.
Have a topic you’d like covered?