{"id":4586,"date":"2023-01-17T11:50:47","date_gmt":"2023-01-17T16:50:47","guid":{"rendered":"https:\/\/cindypotvin.com\/?p=4586"},"modified":"2023-01-17T11:52:28","modified_gmt":"2023-01-17T16:52:28","slug":"coming-up-with-with-my-new-micro-saas-technological-stack","status":"publish","type":"post","link":"https:\/\/cindypotvin.com\/coming-up-with-with-my-new-micro-saas-technological-stack\/","title":{"rendered":"Coming up with with my new Micro SaaS technological stack"},"content":{"rendered":"
For my next project, I’ve been assembling a new technological stack to create micro SaaS apps quickly and cheaply before jumping in the code. I’ve not put it to the test yet, but I figured it would be interesting to share how I’ve reasoned about it.<\/p>\n\n\n\n
I’m now working with small clients, but I was previously working on bigger enterprise projects where the concerns were different, and I’m missing a few tools in my (virtual) tool bag for the smaller, more nimble stuff. I also have ideas that I want to bring to life and I’m looking to build a set of technologies I can reuse across projects and get to the main features quicker.<\/p>\n\n\n
I don’t mind paying for services that save me time or give me a significant advantage, but the main goal is to deploy each additional applications for cheap since they won’t be using a lot of resources, at least at first. <\/p>\n\n\n\n
If I can keep the bar to profitability lower, I can launch more experiments and each micro SaaS will need a lower MRR (monthly recurring revenue) to earn their keep. It’s hard to know application will be a hit, so I want to be able to keep building without adding 50$-100$ a month to my spending for each application.<\/p>\n\n\n\n
Still, I also need to keep my maintenance time low, both since I don’t have a lot of time for my own projects and because I hand off projects to clients and want to keep them as easy to maintain as I can. <\/p>\n\n\n\n
If I can use only a few tools with a minimum of custom work between them, it would be best. I’m trying to save money, but it will be more expensive in the long run if I’m stuck maintaining 20 Ubuntu installs holding random Docker images, and remembering all the glue scripts I came up with.<\/p>\n\n\n\n
I got started on my frontend stack with Divjoy<\/a> as a SaaS template to handle the common boilerplate. It includes many of the tools I was looking to use such as Material UI in the frontend and Stripe for payment. <\/p>\n\n\n\n There are a few other good UI kits that comes with the Divjoy, but I’m already familiar with Material UI: it looks nice and it’s easy to theme.<\/p>\n\n\n\n I also need some JavaScript error monitoring since I won’t always keep a close eye on the application. It’s a toss-up between Sentry<\/a> and Rollbar<\/a>. Their free tier is similar, but I liked the Sentry error management with the little experience I had of it, so let’s go with Sentry for now.<\/p>\n\n\n\n For hosting the frontend static files, I’ll go with Vercel<\/a> since they have unlimited sites. I may also try their Next.js framework at some point with server-side rendering and it just works. Netlify would have been a good option at a similar price point, but their marketing material was not as clear about how many sites were allowed.<\/p>\n\n\n\n Since my projects are simple, I want to aim for a “backend as a service” first and see what else I need if I hit any limits. This should handle all the main backend parts like the database and its api, authentication and file storage.<\/p>\n\n\n\n I’m afraid of pay-as-you-go like Firebase<\/a> since I’m not going to keep a close eye on everything across many applications and don’t want Google to send me a big bill if I make a mistake. I prefer something with a clear cap.<\/p>\n\n\n\n For this reason, I’m going to settle on Supabase<\/a> for my backend as a service. Given that I don’t want to too much maintenance, I’ll purchase from Supabase instead of self hosting it.<\/p>\n\n\n\n Only problem with Supabase is that they’re charging that 25$ per project, but if I structure my data well I should be able to reuse that for all my projects. I can always spin off another project and move the data if I want to sell one of the micro SaaS, or if one really takes off and uses up too much of the quota.<\/p>\n\n\n\n I use Namecheap<\/a> as my registrar already with Cloudflare<\/a> as the DNS server for a few small sites like this blog so I can configure emails and the like separately, so I’ll keep going with that solution. Right now the free plan does the job since I’m only using them for the DNS and some tiny static sites on Cloudflare Workers.<\/p>\n\n\n\n For git source control I already have a bunch of private projects on Bitbucket<\/a> and I have no problems with it, so I’ll stick with it.<\/p>\n\n\n\nBackend<\/h2>\n\n\n\n
Other infrastructure<\/h2>\n\n\n\n