This is the first article in the Designing a SaaS in 2023 series. The series will cover everything from choosing the technology stack and the hosting platform, through designing the back-end services and data storage, to front-end considerations. I'll share lessons I learned over the past decade, the tools I use, and any tips and tricks for working with our chosen technologies. Finally, I will conclude with a look towards the future.

Throughout the series, I will assume my business is hardware-centric with a SaaS application supporting customers. A good example of this is any IoT business such as DIY alarm systems (SimpliSafe, Abode), any smart home company such as Samsung, Wyze or Philips Hue, or automotive smart integrations such as the Hyundai Bluelink, BMW's My BMW or Ford's FordPass. I chose this scenario because it's a bit more complicated than a regular run-of-the-mill web app and my goal is to cover more advanced scenarios. That said, a lot of the thought process will apply to regular web apps too.

Before getting into the meat of said thought process, let's look at some decisions we're gonna have to make before writing that first line of code.

Initial Considerations

Most early-stage SaaS green field projects will need to make key decisions that will stay with them for the lifetime of the product. Build vs buy is going to be one such decision. Depending on your business's core competency, you will want to outsource difficult or time-consuming pieces of your SaaS. For example:

• Authentication. Do you build your own or let an Identity Provider handle it?
• Server-side caching. Do you host your own Redis or use a managed service?
• Logging. Do you store and parse your own logs, or send them to a hosted log processor?
• Front-end components. Do you use an existing library, or build your own?

Deciding what to buy will of course depend on multiple factors such as your budget, team expertise and time horizon. For fledgling startups, buying early on makes a lot of sense. Many SaaS products in the above categories have generous free or low-cost tiers. Here are just some:

• Authentication: Google Identity, AWS Cognito, Auth0
• Caching: Redis Cloud
• Logging: Datadog, AWS CloudWatch, Azure Application Insights
• Hosting: Google Firebase, Render.com, DigitalOcean, Heroku

Let's look at some costs.

Cost of Doing Business

As your application grows, some of these "buy" services will start to become very costly and potentially hinder your growth (especially in the hosting space). Here is one such scenario:

You start out on render.com with five microservices paying $25/mo for a 2GB/1vCPU single instance per service. You have one environment, because you've just started to build. A few months later you're ready to go to production so you create another mirrored environment of five services, but this time, since it's production, you want to give the services a bit more oomph, so you opt for the $50/mo instances. A couple sprints later you're ready to push recent changes to production, but first you want to ensure they work well with production data... so, you need a staging environment. This environment should, optimally, mirror production, so another 5 * $50/mo.

Next, each microservice is going to store data in a silo, so each one needs a database. You choose to use Postgres: (5 $20/mo)... 3, because each environment needs its own data.

Last, we can add some static costs:

• Auth0: $23
• Redis Cloud: $35
• Datadog: $5 (you're not logging much...)

To sum up:

Hosting:

• $25 x 5
• $50 x 5
• $50 x 5

Data:

• $20 x 5 x 3

Other:

• $63

Total: $988/mo

These are very conservative numbers, too. In most cases you will run at least two instances of your production code so that if one goes down for some reason your entire application doesn't fold with it. As more traffic comes to your product, you will want to increase memory and CPU of your hosting machines and potentially add more instances (or let it auto-scale if such feature is available).

Note: We evaluated Render as a hosting platform to reduce Azure spend but decided to pass. Instead, we built out a Kubernetes cluster. Had to learn a lot of DevOps in the process, but now we are saving thousands per month.

Recommendations

It's difficult to give raw recommendations because everyone's situation is going to be different. I can, however, tell you what I would do today if I was starting from nothing given the hardware SaaS company scenario I mentioned earlier.

Authentication Build it. Identity Providers start cheap, but they can get out of control quickly, especially if you're successful and scale up. They do provide easy-to-use SDKs and have nice UIs for user management (except Azure B2C, that thing is gross), but if you're just starting out, you do not need 98% of what they offer you. Instead, use whatever AuthN libraries come with the web framework of your choice. In our case, we used Identity Server 4. In other projects, I used Passport.js. These are battle-tested solutions that give you everything you need out of the box for free.

Hosting Buy it but be strategic about it. In a microservice scenario, it will most definitely be cheaper to run your own Kubernetes cluster (especially if you pre-pay for years of VMs). If you are just building a monolith, hosting it on a beefy PaaS (Platform-as-a-Service) like Heroku or Render is great. The ease of use of these services is a tremendous boon to your productivity and quick delivery to market. I wouldn't try to nickel and dime around hosting by going with a VM like DigitalOcean or Linode, or worse -- self-hosting on your Raspberry Pi.

Caching Buy it. Redis Cloud. No, they didn't sponsor me. It's just the smartest way to go if you need caching (or if you're cool and want to use their permanent storage solution instead of a database).

Database Buy it. Managed databases excellent value. They save you from stress. You don't have to worry about backups and when you scale, your databases scale with you, including to other continents! Schema migration went awry? No problem, do a restore. All you need is a connection string and you're off to the races.

Logging Buy it first but build it later. When your product becomes complex and has hundreds or thousands of try/catch blocks, and each service has several instances, it's easy to flood logging services with records resulting in excessive costs. The thing about logging is that it's conceptually quite simple. Many logging libraries support bringing your own "sink", which you can then use to deposit logs to a datastore of your choice, aggregate it, write your own retention policies and so on. This is of course way later, but in my experience, logging costs at larger scale can get ridiculous, so it's worth exploring an in-house solution once you have the engineers and capacity to build it.

Front end components Get it for free or build it. You may be tempted by pretty, premium component libraries, but the truth is that customers aren't gonna keel over from overwhelming wonder when they see a premium pie chart versus a c3.js one. Tables, dropdowns, multi-selects, they can all be either found for free in the OSS community or straight up written yourself. We used Buefy (a VueJS lib), and we'll stick with Bulma CSS going forward, but personally I've also experimented with Tailwind and Uno when writing my own custom components. There are many awesome, free component libraries out there, so... don't buy.

In Conclusion

There are many items on the check list when spinning up a new SaaS. The goal of the next few articles in this series will be to do a bit more of a deep dive into specific topics mentioned at the beginning of this article, beginning with choosing your tech stack!