What’s the first technical decision you lock in when starting a new SaaS product?
by•
For me, I feel like the hardest part isn't choosing between tools like React, Firebase, Railway, etc, it's really deciding which parts of the stack I should commit most of my time and tokens early and which ones may become painful to replace later.
Do you stick with a familiar stack and avoid overthinking it, design around expected scale from day one, let your coding agent influence the architecture, or start with the cheapest setup and migrate later? Also, curious which early technical choice has saved you the most time, and which one you wish you probably shouldn't have overthinked on.
190 views
Replies
@maxitencent has keeping things boring ever turned out to be your best decision?
I prefer deciding deployment and database before fronted details because those choices stay longer. Have you ever regretted picking managed services too early or did they actually reduce maintenance enough to justify the cost later?
i focus on keeping services loosely connected from the beginning. swapping authenication or storage becomes much easier when everything depends on clean interfaces instead of direct integrations. That decision has paid off repeatedly.
Good organization makes debugging testing and onboarding much smoother. What folder structure has stayed reliable for your recent projects?
@maxitencent Which upgrade surprised you the most after real customers started using your product every day?
I spend the most time choosing authentication because replacing user identity later creates friction across the whole application. Everything else feels easier to change once accounts permissions and security are already stable.
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?