In the previous article in this series, we covered some initial considerations when starting a SaaS business. Here, we'll cover choosing the tech stack to build your application with. I know this choice can be emotional. Developers have their preferences and will man the barricades in their defense.

In the real world, Gin is not a framework you're gonna be able to hire easily for. Nobody builds enterprise-grade apps with Laravel. Good luck getting audited for an IPO running on Node. And yet, Gin, Laravel and Node are excellent platforms to build on. I have written public-facing applications using two of those! Would I choose them for my SaaS though?

Maybe. Depends. Some questions first:

1. Will this tech be supported 10 years from now?

2. Will I be able to hire people who can work with this tech?

   1. Is the tech appealing and easy to get started with?

   2. Does it have a large community?

3. Are there any potential security or performance issues with the tech?

   1. These could be non-existent at low user volumes but start showing up as the user base grows.

4. Will I enjoy working with this tech?

Answer the above questions for the tech stack of your choice. If you answer "yes" to all four, you may have a winner!

Let's explore the various parts of a SaaS and answer some questions.

Middle Tier

I'm familiar with .NET, so I'll use that as an example.

1. .NET has been around since the mid-2000s, and Microsoft is not about to let go. I'm confident .NET will be around for many years to come.

2. There are many .NET developers. Hiring should be no problem. Since .NET Core and more recently .NET 6.0, the stack is quite easy to get started with and the documentation is phenomenal. Since the framework has been around for 20 years, the community is huge too.

3. There are always gonna be potential security and performance issues with any framework, and .NET is no exception (look at EF Core early on, what a mess). However, Microsoft is particularly good at patching those up and their release cadence is clear and solid.

4. I enjoy working with .NET 6.0. C# specifically is an awesome language. C# 7 and recently C# 10 introduced a lot of modern features and made coding less verbose and just generally a better user experience.

Backend

Though I've done a bit of React and Angular, my framework of choice is Vue.

1. Vue has been around a while, it has a large community and lots of support. The OSS community backs it, so I don't have to depend on a corporation to keep it current (see Angular...). Vue checks out.

2. Vue may be difficult to find developers for, but it's extremely easy to pick up, so anyone with generic JavaScript knowledge should be able to fit right in. As mentioned above, the community is huge so getting help should be easy.

3. JavaScript has had a tough time with performance and security. Today, it's in the best place it has ever been, but still has ways to go. Vue 3 is a significant performance improvement over Vue 2, so chances are Vue 4 will be too. I trust it.

4. I love working with Vue (Svelte close second!), so no problems there!

Data

Data storage is a different story. Though some of the questions still do apply, database choice is a matter of need rather than want. Some key points:

• If your data is relational, you'll want to use a SQL database. SQL is also the most common way to store business data and is easy to hire for. There are a lot of choices here, though I would highly recommend a cloud-hosted managed solution. Cockroach DB, Azure SQL, or any cloud-hosted SQL database honestly.

  • Self-hosting a database is a lot of work. Automated backups, geo-replication, etc... It's a lot of overhead. Better just to pay!

• If you're building out a microservice infrastructure, you're going to silo each business entity behind an API. This means you can use document storage like MongoDB, Azure Cosmos, Google Firestore, or even Redis.

  • Joining between entities will happen in the API Gateway layer.

• Binary file storage is straightforward. Amazon S3, Azure/Google Storage. There are several options here so depending on which cloud hosting provider you go with; you'll want to go with that solution.

There are some other data storage solutions such as a graph database, which have niche applications. It's worth it to spend the time to proof-of-concept different solutions and use different data stores in the process.

Last, but not least

Some questions which I didn't ask above but should be considered:

• If my business is successful and I'm getting bought out (or going public), will I pass a security audit?

• Does the front-end/middle-tier framework have SDK support for the data backend I want to use?

• Do my financial backers have a say in the tech stack? Some VCs may have enough technical chops to butt into your technology choices.

Also, depending on the size of your application, you may want to mix-and-match services from different hosting providers. For example, I have an application running on Render, static assets hosted in Google Storage and data sitting in Redis Cloud. When creating these, I made sure to put them all in the same geographic area (US West in my case) to reduce performance implications when my middle tier must talk to my database.

Choosing a tech stack is a monumental decision which will stay with you for many years, if not forever. Moving infrastructure, migrating data or switching frameworks are time-intensive and thus expensive endeavors. Sometimes switching is unavoidable due to product End-of-Life or hosted service deprecation. A cloud developer's job is to anticipate all the plays and lead their team to victory by making the right decisions at every opportunity! Don't be afraid to pivot should a choice you made turn sour either. Lastly, don't over-complicate your architecture. Your microservices may not need an event hub or a pubsub to communicate. You may not even need microservices. Hell, your app may not even need a middle tier -- perhaps Firebase, Supabase or Pocketbase is all you need...