What’s the first technical decision you lock in when starting a new SaaS product?

@maxitencent Has shipping quickly ever forced you into painful rewrite?

@maxitencent Which upgrade surprised you the most after real customers started using your product every day?

@maxitencent What's the earliest decision you still revisit halfway through a project?

Everyone is asking Maxi questions, so here is an actual answer.

Stack: whatever I already know. Which framework, which database, none of that decided anything for us.

The one I would lock in on day one is the tenancy boundary. Every table gets an org id in the very first migration, and every query goes through one layer that cannot forget to filter on it. Bolt that on later and it is not a refactor, it is every query you have ever written.

Second one, less obvious: where the data physically lives. We are EU hosted. It reads like a checkbox until a German customer asks, and then it is the whole conversation. Changing region later is a migration plus a legal problem.

What I overthought: the framework. Not one of our real problems came from it.

Has anyone actually retrofitted multi-tenancy without a rewrite? I have never seen it done cleanly.

Has anyone measured how much time migrations actually consumed compared with rebuilding interfaces? a

Mostly early products need customer feedback before distributed systems. Would starting simple with clear upgrade paths be the safer long term strategy for most founders?

I would argue auth is the one worth locking in early, and it is precisely because of the point you made about things that become painful to replace later. Most of the stack is more forgiving than it feels in the moment. You can move from Railway to Fly, swap a database, or even change frameworks with enough effort, and your users never really feel it. Auth is the opposite. The moment you have real accounts, your identity choice is wired into your data model, your APIs, your sessions, and your security posture, and pulling it out later means migrating live credentials and hoping you do not lock anyone out or open a hole while you do it.

The nuance I would add is that locking it in early does not mean building the full enterprise setup on day one. It means picking an approach that will not force a painful migration once you grow, so you can start simple and add SSO, roles, and everything else without tearing anything out.

On your last question, the thing I see people overthink is usually the framework and the hosting, which are cheap to change, and the thing they underthink is auth, which is expensive to change. If I were starting again, that is the order I would flip.

How are you leaning on it for this one?

I’d usually lock in the data model and auth/permissions first. Frameworks and hosting can change later, but if the core entities, ownership rules, and user roles are messy, everything becomes harder to fix. For early SaaS, I’d rather use a familiar stack and move fast, but be careful with decisions that touch data, billing, and permissions.

The first thing I try to avoid locking in is vendor-specific logic. Frameworks are relatively easy to swap, but once your business logic is tightly coupled to a database, auth provider, or cloud service, every future change becomes expensive. Keeping those boundaries clean has saved me far more time than picking the "perfect" stack.