Software Engineering – Cindy Potvin

January 17, 2023

Coming up with with my new Micro SaaS technological stack

Entrepreneurship, Programming, Side Project, Software Engineering, Web Development

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.

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.

Main goals

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.

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.

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.

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.

Frontend

I got started on my frontend stack with Divjoy 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.

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.

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

For hosting the frontend static files, I’ll go with Vercel 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.

Backend

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.

I’m afraid of pay-as-you-go like Firebase 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.

For this reason, I’m going to settle on Supabase 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.

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.

Other infrastructure

I use Namecheap as my registrar already with Cloudflare 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.

For git source control I already have a bunch of private projects on Bitbucket and I have no problems with it, so I’ll stick with it.

Finally, I’ll be adding UptimeRobot to minimally keep an eye on things and check if each project is still up. The free plan should be enough for my needs for a while since it can monitor the uptime of 50 “things” such as a SSL certificate or a specific page. I’m probably just going to monitor a single page that requires api calls for each project since most elements are provided by third-party services.

Starting budget

Here is how it should cost to keep all my micro SaaS up, at least while they are small:

Products	Pricing (in USD)
Vercel	20$ for the cheapest commercial tier with 1TB bandwidth and preview deploys.
Sentry	0$ for 5k errors logged. I doubt I’ll reach the 26$ plan with 50k error anytime soon.
Supabase	25$ for the paid tier so the database stays up.
Cloudflare	0$ for the free tier with unlimited DNS server.
Postmark	10$ for the first 10 000 emails a month, transactional or newsletter.
Bitbucket	0$ for the free tier with unlimited private repo.
UptimeRobot	0$ for 50 free items monitored.
Domain name	About 1$-ish by domain depending on the TLD.

So I’m looking at around 55$ +1$ each for the domain to run a bunch of tiny SaaS applications, not bad!

If I do make a sale I’ll have Stripe fees at the minimum, and I’ll need to do support and marketing but that will need to be considered in each product’s pricing.

My next step is now to try this out with my next micro SaaS to see if I missed anything and how it will turn out.

December 19, 2016

Are You Hard to Convince?

Programming, Software Engineering

When discussing a new technology, I’m rarely the first one to jump on the bandwagon. In fact, I’m usually the killjoy that ends up arguing against using a new library or a new language feature when the enthusiasm is high and everybody is eager to get started.

It’s not that I want to stay comfortable and never move forward. Rather, I need to be convinced that something is worth it instead of moving for the sake of it. New features and libraries can add complexity to something that’s already complex. That makes it harder for new people to join in (including you if you didn’t touch it for the last 6 months).

I’m all for new ideas that makes software easier to understand and that allows me to do my job better. Still, the argument about new technology is too focused on the shiny new technology itself, and not the problem it solves. A great idea is not enough; it has to work well in the real world.

To illustrate this, I choose a few templating engines at random on npm (not judging their quality; maybe they’re all great). Here is the kind of descriptions that will greet you:

Why should I choose one over the other, or use it to replace an existing tool? A description like fast and powerful is not very helpful. It’s good to have, but who would pick a underpowered, slow engine?

Of course, if I’m looking specifically for an HTML template engines I can narrow it down a bit, but if I don’t have a strong preference one way or the other, what should I choose? There were surely a few problems or use cases that led to writing those engines instead of using an existing one, but I don’t have any way of knowing from looking at this.

At this point, I’m asking myself if the library will still exist in 5 years (without forcing me to rewrite everything every year) and if it’s well documented so I can get up to speed quickly, not if it implements a cool pattern in particular.

If I had to choose something for a project from that list, I would probably pick the ones that have the most promising documentation and a large following, and try them out for myself. Granted, it could still blow up later in production or when trying to implement a feature in particular since I’m only coding a prototype, but it’s better than nothing.

But after doing all this work, why would I switch to something new a few years down the line if the one I choose first still works well? I have to be really convinced that it can solve my problem better, and that is worth the cost of switching in improved productivity and ease of use. With the speed that the technology is moving I must be sure it’s worth it. I can’t afford to waste my time migrating to something that will make things worse.

July 5, 2016

Your job will never be done

Learning, Lifestyle, Software Engineering

As a software developer, you have to become comfortable with the fact that your work is never truly done. The software you create will always be a work in progress. When you code that last feature or fix that last bug, another one will pop up soon enough.

Also, as you keep learning, you’ll find better patterns that you want to use, or new standards that you want to implement. If you don’t stop yourself, you’ll quickly go down the rabbit hole, only waking up after you’ve sunk many hours to refactor your whole code base. At some point, you have to let it go and ship anyway, because it’s never going to be perfect.

Good software is like a garden. You can pull all the weeds and clean up, but be quick to congratulate yourself because it will stay neat for approximately a day. After this, new weeds will have grown and you’ll have to start over again. Perfection is fleeting in software and in gardening: the best you can do is making sure it’s not overrun by weeds and bugs.

Likewise, there are new languages, frameworks and tools coming out all the time, and you need to keep learning to stay up to date. You don’t have to jump on every bandwagon: many skills can be learned as you need them. On the other hand, changes like new browsers and OS versions will force you to adapt even if you would have preferred working on a new feature instead.

It’s humbling to let go if you’re a recovering perfectionist. When you started out, small problems could be “solved”, and a class could be “completed”, but real life is more complex than this. Life will throw you curveballs, and you won’t be able to reach inbox zero. It won’t come easy at first, but stay mindful that you’re doing your best, but can’t do it all. You’ll learn to be at peace with it, but even this is always a work in progress.