I recently

to embark on another adventure, as an Indie Hacker/solopreneur (call it whatever you like).

I've got several projects that have been gradually coming off the drawing board over the last few months:

• an opensource static blog engine using Nuxt and Nuxt-content, which allows me to create this blog in particular

And I've got two SAAS in the works, not yet fully released:

• TubeTally.com, not yet public, an analytics tool for Youtube
• RssFeedPulse, a SAAS for creating newsletters from RSS feeds, ideal for static blogs.

The second is close to being open to the public. I already use it for myself, and if you subscribe to this site's newsletter, you'll be using it indirectly.

Each of these projects was built in less than a week.

But, excluding the YouTube channel, there's a big difference between "building" a project, and making it public.
There's a world of difference between developing a product and making a living from it.

Before developing :

• how do you choose to work on an idea?
• How do you choose a product name?
• How do you define your pricing model?

And once the product is developed

• How do you find a domain name?
• What do we put in the site's "legal" pages?
• How do you collect payment, and which software do you use?
• How do you invoice?

I'm not going to cover everything in this article, especially as some subjects are still ongoing. But, if you're interested, I'll be talking a lot about it on this blog over the next few months, so stay tuned (subscribe to the newsletter !).

Today, however, I can tell you about the technical stack I've decided to use.

My constraints

Before talking about the stack, a quick reminder of my main constraint: money
and I include time (because time is money ^^).

For me, a technical stack must be :

• easy to deploy (no time to waste)
• inexpensive to RUN (RUN = run in production)
• productive, i.e. my developer experience should enable me to develop very quickly

On a SAAS, I try to avoid "Hype driven development", so there's little or no shiny new technology to learn as I create the product.

However, as the ecosystem for running front-end applications has evolved quite a bit over the last few years, I've allowed myself a little deviation from this rule by evaluating the use of Supabase.

General architecture

The general architecture, i.e. which major technologies I'm going to use and how they're going to communicate with each other, is one of the main choices that will determine the type of hosting I'll use, and therefore the cost and services I'll need to add to make it all work.

Let's take an example.

I hesitated to use Nuxt-Hub to deploy a full-stack app on the Edge.
So, that's a lot of complicated words. Let me clarify.

With Nuxt, you can deploy an application with a frontend, and a backend (apis for example), entirely on the Edge. Like a CDN, the Edge is a server very close to the user. The Edge is generally inexpensive and high-performance.

Cloudflare offers quite a few edge services, notably a database, it's SQLite and the cost is very, very competitive.

An alternative would be to use Supabase. Supabase also offers a database, postgresql this time, but also a whole ecosystem of services, serverless functions, authentication modules and so on.
The cost is also very competitive. It starts at 0 on a very generous free tier. Then it drops to 25 euros.

I confess I wasn't seduced by the scheduling possibilities (having jobs and workers systems) of the two architectures above.
Unsurprisingly, there are services that compensate for these weaknesses, such as trigger.dev, but these are extra euros to spend.

I also have to admit that I don't like the proposed developer experience (need to use docker for supabase, typing of model objects, and logs, especially on the server side!)

So I went back to a more standard architecture for me:

• a kotlin api
• a front end that consumes the api (in Nuxt)
• an openapi contract between the two (nothing to do with openai!!)

Frontend technology

On the front end, I chose :

• Nuxt
• Tailwind

I'm not originally a front-end dev, but I feel particularly productive with these two technologies. It's also what I use for Bloggrify (which powers this blog).

Nuxt runs very well in SSR (server side rendering), CSR (client side rendering) or hybrid. So it's a very good candidate for meeting any future SEO constraints I may have. The developer experience is very good.

Backend technology

The backend techno is rather classic, as far as I'm concerned:

• Kotlin (language that runs on the JVM)
• Spring Boot
• Postgresql

Hosting

I chose to start with Clever cloud for about 20 bucks a month (16 euros DB, 5 euros application).

It has the disadvantage of being more expensive than the free tiers of its front-end equivalents, and offering fewer features (than Vercel, netlify, supabase, cloudflare). But I feel much more comfortable with the stack.

I'm not saying my stack is perfect, I'm saying I'm productive with it, which is very different.

I discarded richer options, like cloud run, which would have allowed me to benefit from scaling to 0.
Scaling to 0 means that no resources are consumed when the application is not in use.
But Cloud SQL (GCP's managed database) is far too expensive.
I absolutely didn't want to manage my own database. It would have been possible for less than 5 euros with a lot of options. But I have no desire to manage it manually.

I considered options like fly.io or koyeb which have scaling at 0 and sometimes also have a price for Databases that differentiates compute (time of use) and storage (database size). But I was a bit annoyed by a sometimes less readable pricing model, which seemed higher, or the fact that Java/Kotlin wasn't directly supported, so I had to create my own docker container.

The perfect stack

To create a SAAS in a week, there are a multitude of options.
But there's no such thing as the perfect stack.

Unless you consider that the perfect stack is the one in which you feel comfortable creating your SAAS in a week.

The ability to deploy an idea quickly remains paramount. You don't need to spend weeks testing every possible architecture, evaluating every possible technology, or implementing complex solutions. With practice, your stack should enable you to put a new app into production in less than 2 days (including dev time).

And that's why I didn't study every solution, test every PAAS provider. I took the solution that seemed simplest/quickest for now, and I may come back to it later. It's better to make a bad decision quickly than a good decision slowly.