Choosing a tech stack for a new SaaS product is one of those decisions that feels monumental at the time and then, about eighteen months later, you realise it mattered far less than you thought. Or far more. It depends entirely on whether you made the decision for the right reasons.
I have shipped four SaaS products over the years. CampSuite, Crocodile, RealCube and Lavida. Every single one involved a tech stack conversation, and every single one taught me something different about what actually matters when you are choosing the tools you are going to live with for years.
So here is how I think about it now, after getting it right a few times and getting it wrong at least once.
The tech stack debate is mostly noise
Let me get the controversial bit out of the way first. Most of the tech stack debate you see online is absolute nonsense. Developers arguing about React versus Vue versus Svelte, or whether Go is better than .NET, or whether you should use Postgres or MySQL. It is like arguing about whether a hammer is better than a screwdriver. It depends what you are building.
The truth is that almost any modern tech stack can build almost any SaaS product. The language and framework you choose will not determine whether your business succeeds or fails. Your ability to ship features, fix bugs and keep customers happy will. The best tech stack in the world is worthless if you spend six months debating it instead of building something.
That said, the choice does matter. Just not for the reasons most people think.
What actually matters when choosing a stack
After twenty five years of building software, here are the things I actually care about when picking a tech stack for a new SaaS product.
Can you hire for it? This is the single most important factor and the one most founders completely ignore. You might love Elixir or Rust or whatever the hot language is this year, but if you cannot find developers who know it in your budget and your geography, you have just created a massive scaling problem for yourself. When I chose .NET for CampSuite, one of the biggest reasons was that I could find solid .NET developers in the UK without selling a kidney. That matters more than benchmark performance.
How mature is the ecosystem? Mature ecosystems have battle tested libraries, comprehensive documentation, active communities and established patterns for common problems. When something goes wrong at two in the morning and your main customer's data is not syncing, you want a stack where the answer to your problem is already on Stack Overflow. Boring technology is reliable technology, and reliability is what pays the bills.
What does your team already know? If you have a team of three developers who are brilliant at Python and Django, do not start your new project in Go because some blog post said it scales better. The productivity loss from learning a new stack will cost you months. Months you do not have when you are bootstrapping. I talk about this a lot in The 28 Day Startup because it is one of the biggest time sinks I see founders fall into.
Does it match your deployment model? If you are deploying to Azure because your enterprise customers require it, picking a stack that works beautifully on Azure makes your life dramatically easier. CampSuite runs on Azure with .NET and SQL Server. That is not because .NET is objectively the best language. It is because the entire ecosystem works together seamlessly and our customers already have Microsoft agreements in place.
My actual stack choices and why
For transparency, here is roughly what I have used across my SaaS products and the reasoning behind each choice.
.NET has been my backend workhorse for most of my career. It is fast, well documented, integrates beautifully with Azure and the Microsoft ecosystem, and the developer pool in the UK is excellent. When I am doing consulting work or building something that needs to integrate with Dynamics 365, it is the obvious choice. Is it the sexiest stack? No. Does it ship reliable software that makes money? Absolutely.
On the frontend, I have used everything from jQuery through Angular to React. The honest truth is that for most SaaS products, the frontend framework matters less than people think. Pick something your team knows, that has a large community, and that you can hire for. React has been my default for the last few years simply because the talent pool is massive and the ecosystem is mature. That is not a technical argument. It is a business one.
For databases, I default to SQL Server when the project is Microsoft ecosystem heavy, and Postgres when it is not. Both are excellent. Both will handle anything a typical SaaS needs to throw at them. I have never once lost a customer because of my database choice, and I suspect neither have you.
Mistakes I have made so you do not have to
The biggest tech stack mistake I ever made was over engineering the initial architecture. On one of my early products, I built a microservices architecture from day one because that is what all the conference talks said you should do. We had about fifty users. Fifty. We did not need microservices. We needed a monolith that shipped features fast. I spent weeks wrestling with service communication patterns instead of talking to customers and building what they actually wanted.
Start with a monolith. Seriously. Unless you have very specific scaling requirements from day one (you almost certainly do not), a well structured monolith will serve you perfectly well until you have enough users and enough revenue to justify the complexity of splitting things apart. Every successful SaaS I know started as a monolith and split later if they needed to. None of them regretted starting simple.
The second mistake was chasing performance before I had a performance problem. I spent days optimising database queries for a product that had twelve concurrent users. Twelve. The queries could have been written by a graduate and it would not have mattered. Premature optimisation is real, it is seductive, and it will eat your development time alive if you let it.
The third mistake was not thinking about operational costs early enough. Your tech stack choice has real financial implications. Some cloud services are cheap to start but get expensive fast. Some frameworks need more server resources than others. When you are bootstrapping a SaaS on your own money, the difference between a fifty quid a month hosting bill and a five hundred quid one matters. A lot.
What I would do if I started a new SaaS tomorrow
If I was starting a brand new SaaS product tomorrow, here is exactly what I would do. .NET 9 on the backend with a clean API. React on the frontend because the developer pool is enormous. Postgres for the database because it is free, reliable and handles everything I would need. Azure for hosting because I know it inside out and it plays nicely with the Microsoft ecosystem that most of my enterprise customers live in.
Monolith architecture. No microservices, no event sourcing, no CQRS, no hexagonal architecture. Just a clean, well organised monolith with clear separation of concerns. I would add complexity when the product and the revenue justified it, and not a moment before.
I would use a managed database service rather than running my own. I would use a managed Redis instance for caching rather than building my own cache layer. I would use a third party service for email sending, payment processing and authentication rather than building any of those things myself. Every hour I spend building infrastructure is an hour I am not spending on the features that make customers pay me money.
The real decision framework
Here is the framework I use now, stripped down to the essentials. Ask yourself these four questions in this exact order.
First, what does your team know? Use that. Second, can you hire for it in your market? If not, reconsider. Third, does it match your deployment and customer requirements? If your customers are enterprise Microsoft shops, going all in on AWS and Python is going to create friction. Fourth, is it boring enough to be reliable? If the framework's documentation still has "coming soon" sections, it is too new for your production SaaS.
If a tech stack passes all four of those questions, it is good enough. Ship the product. Talk to customers. Make money. You can always refactor later when you have revenue and a team to do it properly.
The founders who succeed are not the ones with the perfect tech stack. They are the ones who picked something reasonable and then relentlessly shipped value to their customers. Do not let the tech stack decision become a procrastination mechanism. Make the call, commit, and build something people want to pay for.
