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
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.