Introduction
Firstly you might be asking, "What is a SaaS?" - a SaaS (Software as a Service) is often referred to as a web application where you charge money to access it. For example, an invoice tracking platform that you pay $5 a month to access would be considered as a SaaS.
I have come across an assortment of tools and frameworks over the years that aim to simplify the process of building an application. During that time I have seen countless tweets telling people to use framework X over Y, with the argument often being one of these:
- "X uses a modern programming language"
- "X scales better than Y"
I see these arguments on a regular basis and often find them very silly, I'm a firm believer that programming languages and frameworks are all tools that achieve the same end goal - building a web application.
Scaling shouldn't even be a concern as a start-up otherwise you'll end up slowing yourself down and over-engineering your application. Worry about those issues when the time comes, not now.
With that, I'll now explain the set-up I am personally using to build my SaaS businesses..
My Stack
When building a SaaS I believe you should use the tools and frameworks that you are already familiar with, and so with my experience of Vue.js I'm able to utilise other frameworks like the ones I will mention below.
Landing
When working on a SaaS I always like to have the landing page, blogs and documentation in one codebase which deploys to static HTML (.html) files. I use Nuxt 3 as it utilises Vue.js, I also utilise their Nuxt Content plugin to power the blogs and documentation.
Nuxt Content allows me to write my articles and documentation in markdown (.md) files. This makes it easy to write and maintain without requiring me to style titles or paragraphs each time. The website is then deployed to Vercel just by deploying to GitHub, which makes writing and updating documentation a breeze.
Dashboard
I already knew Laravel and Vue.js so I stuck to these with building my SaaS. I like Laravel because it comes with scaffolding options for authentication, allowing me to focus directly on the core of my app instead of being stuck on email verifications.
I went with Vue.js as it was straight forward and easy to use, but also powerful enough for state management and handling for my application. While React.js is often promoted especially on Twitter, I personally found it to be too complex for even simple tasks and isn't beginner friendly.
For this I went with the VILT (Vue.js, Inertia, Laravel & Tailwind CSS) stack, I could utilise my knowledge of Vue.js and Laravel to build my application. I could quickly style my application with Tailwind CSS through utility tagClasses, without spending hours writing thousands of CSS code and having to remember class names.
Finally, Inertia would allow me to bridge my Laravel application with Vue so I could passthrough any information from the database to my users.
Database
For many years I have used MariaDB as my database solution, it's an optimised fork of MySQL that has worked flawlessly with my previous SaaS applications. I never faced any bottlenecks using MariaDB until we surpassed the 90 million record range. By this point we started facing constant freezing which I was able to overcome by implementing server-side caching but not ideal.
It wasn't until I started building my recent SaaS (Analyse) that I knew we needed a more robust solution. I knew we would surpass 100 million records in a short period of time and caching wasn't the answer - ironically we did, in our first 6 months!
After looking at other database solutions I found nearly all of them required me to either learn a new query language, wasn't MySQL compatible (requiring rewriting queries) or I needed to main 2 databases. With my motive to move fast, learning new languages and rewriting queries wasn't on my bucket list. I certainly didn't want to host one database for my application, and another for records that need to be stored and retrieved quickly.
SingleStore
After hearing about SingleStore from a Fathom Analytics article I decided to give it a go - I was blown away! It took small tweaks to my table schema (Like removing foreign key constraints) in return for a massive boost in performance. I didn't need to learn a new query language or rewrite my existing queries, it just worked.
When I first saw that SingleStore offered a free self-managed version, I was skeptical that we would face issues as we got larger due to it being free. Admittedly, I was massively wrong! The free tier has allowed us to rapidly query and store more than 120 million records, it's such a great feeling that I can host this off our existing infrastructure, for no extra cost.
Hosting
When deploying my SaaS to production I always host on "bare metal", this is when you pay a flat fee per month to rent hardware in the cloud. The advantage is that you know your exact expenses each month and own that hardware for how ever long you rent it for.
For this reason I use a AX41-NVME from Hetzner to host Analyse, a beefy machine that comes with 64gb RAM, 512GB SSD and a great Ryzen CPU. I run my SaaS and SingleStore on this machine and even with thousands of customers and more than 120 million records, we only average at a 1% load on the CPU which is mind-blowing.
Not to mention we currently receive more than 30 million API requests every month!
What about Serverless?
I see this brought up a lot with many recommending serverless to others building a SaaS. The common argument for going serverless seems to be any of the following:
- "3am wake-up calls"
- "Dealing with server maintenance"
I'll be honest, in the 8 months since my SaaS launched I have not once had to deal with any of these. Nor have I had to deal with these in previous years with other projects, I'm sure it happens but nowhere near the frequency people claim, it's scaremongering. These people go then rush into serverless, don't configure it correctly and wake up to a huge bill for misconfiguring it.
Don't get me wrong, the principle of serverless is great but it's over-hyped and I wouldn't recommend it until you are at the scale where these issues happen often. Start small and affordable and upgrade when the time is right.
I have seen it happen where people go serverless this early on, they end up spending $45+ a month on AWS and Laravel Vapor only to get 5 users and make $0 in revenue for ages. If you start on a small $5 Digital Ocean droplet, you can scale it up when the time is right - you'll probably find that will last you for a long time.
Analytics
Analytics are a crucial part towards building a SaaS for gauging interest, finding where visitors come from and when your site is most active. I find this to be a helpful indicator for knowing quiet spots, usually a great time to launch a new feature or update a dashboard.
Many turn to Google Analytics for tracking this information, and while it certainly works it also breaches your visitors privacy. Google are known to use your visitor data for their advertising system, this is the same reason why Google do not charge for access.
To make matters worse, Google Analytics is considered illegal in many countries and using it on your site could open you up to legal trouble. This is why I use Fathom Analytics when launching a SaaS, they charge a small fee but offer privacy-focused analytics. As an added bonus, Fathom isn't picked up by ad blockers unlike Google Analytics, making your dashboard more reliable to depend on.
Payments
When it comes to generating revenue I use Paddle, they have a fantastic support team and also support PayPal which my target audience primarily use. By being a customer of Paddle you also get access to ProfitWell, an awesome platform that provides additional visibility into your revenue.
As an added bonus, I love how active their CEO (Christian Owens) is on Twitter. While it's not a reason to switch over to them I find it shows their commitment to providing great support.
Final Notes
This article is a first revision and will be updated over the coming days with more information.