Finding the perfect side project stack

In this blog post I will document a recent research for a tech stack for my side projects, or really just how I would start a real project in July 2021. These are obviously very personal choices and this is not the stack I work with on my job. That being said, I do enjoy the search for a stack that allows focusing on developing an idea that I have, leaving as much as possible all the annoyances behind.

Side projects

I work on side projects all the time, I have made themes in themeforest, started apps on android store, launched a sass app for teams to share revenue (mostly for Envato users), launched last year Haynet which is still in it's infancy and trying to find some sort of market fit, and I am starting to work on a new project for an idea I have been playing with for a while. However, this time I wanted to take some time and invest a bit into a research on what tech stack to go with for the next years building this kind of projects.

The choices made here are naturally very driven by the fact that I am a frontend developer who just enjoys working with React and components in general, so take it as you like. I did already start my last project in this new stack and so far it's going out really great and because it took some time to find the right pieces I though would be useful to share them with you.

Motivations and preferences

Before we get into the tech choices, I thought would be good to first discuss a bit the things I find value in for this kind of project (where it's just me working on it), and things I did want to very explicitly have in the stack I was looking for.

Sass (software as a service)

Most of the things I am trying nowadays would fall into the Sass (software as a service) category, there is just something so appealing about the subscription model and the whole recurring revenue, having one product to work on and improve and iterate on, discuss problems with clients, solve real world problems with software. That is after all what I really like doing.

So some of the choices made here are based on this fact, that the end result has to have some sort of built-in sass features (pricing, auth etc..)

Development speed

The choices I make here are for side projects. Some will live longer, some will not even see the light of day, some others might live for just a little while. Mostly I am trying real ideas to see if they have any kind of interest, or sometimes just to see if I can even make them start to finish.

So it's quite important that I can do this as fast as possible.

Backend as a service

I am a frontend developer, and I can't possibly say with enough emphasis how much I dread databases. I really do, I hate them. It's a must for me that I am not directly maintaining any kind of database myself for these projects. So this is a pretty big factor in my choice process, that I need some sort of backend as a service (Hasura, firebase, Supabase etc.)

Simplicity

This is kind of a difficult one to express, and it's very tied to the Development speed motivation. The stack needs to be simple (I know right?), I need to already know it (I want to solve a business / idea problem not wrestling a new technology or language) so I need to keep things simple, maintainable and small.

Authentication

This is a funny one, somewhat related to previous motivations as well I guess.

Whatever backend as a service I choose should have authentication built-in. It's just not a problem I am really interested in solving (again). If the backend does not have it I would have to use some other pre-made service for authentication. I just don't want to handle authentication myself for these projects.

Simple (very simple) hosting

Hosting must also be a non-issue. It needs to be a git based hosting solution where I basically push my code and boom, it's live.

Other features for hosting are also important, especially preview URLs for branches which allows me to share a "preview feature" with people or myself to test before merging to main.

Open source

As much as possible keep things in the open source world. You never know what tomorrow brings, companies have pricing models that change on your feet, companies disappear because they took too much funding and let projects die, etc.. I can't guarantee that any of these projects will actually make real money (most do not), so I need to make sure it's only my time I am playing with.

Tech choices

Ok, now that we are clear on where my motivations lay, let's dig into the actual technologies and tools I am using.

Next.js

Alright, how can I say this without sounding like a total next fanboy..well, honestly I don't care about sounding like that since it's exactly what I am. Next.js is the first choice I made (before even consciously making it), and it's because honestly I just love working with it so much (here I feel like i am entitled to do this). I use Next.js in my day job too and in all the years I have been doing web development (with several frameworks from .net, umbraco, wordpress, joomla, cakephp, drupal, angular) nothing has ever struck to right amount of flexibility, opinions and direction that Next.js strikes for me. Working with it (and largely due to React as well) I just feel so productive and quick. It just puts me right on the pit of success in terms of end user experience, developer experience, speed of development and best practices.

I honestly don't see myself working on anything else (ofc I would if I would have to, but I don't need when I am making these kind of choices) since this started clicking for me.

The other reason I love Next.js is that they just have the same mental model and motivations that I have on this kind of project (and any project really..). They believe (and I believe too) that product and product experience should drive the tech decisions and not the other way around. It's very well suited for developing products and so it's for me a non-negotiable choice.

Vercel

Lets get to hosting because this one is also a quick one. I love working with Vercel, I admit Netlify (which I also use at work) is pretty nice as well, but when I debate the two of them (and this might sound ridiculous) I choose vercel because they "gave birth" to Next.js and it's a "very" small way of me to thank them, and if I get to pay them for this I will be happy to do so.

Using Vercel is simple, its quick, and I admit that my hosting requirements are indeed small but Vercel ticks all the boxes perfectly.

Supabase

This is a recent choice, I previously was doing everything in Drupal when it comes to the backend because it's something I have worked with for so many years, I am familiar with it. But recently Drupal has grown way to complex for my needs here and like I mentioned before I don't want to maintain a database (and also a different tech stack for the backend) so "something as a service" was what I needed when it comes to the backend.

I tried some things to solve this particular part of the puzzle, and it is the part that took the longest for me. And because I knew this is where my weakness is at, I would need something really simple and powerful.

Strapi

I really like CMS (Content management systems), I have worked with CMS (especially Drupal) for a very long time (almost my entire professional career) and so I gave strapi a spin, it was really great. The admin interface is great, modeling data is super easy, and it's javascript which keeps everything in the same language (Next.js is also javascript) and so it seemed like a great choice. Unfortunately there were some things that led me to choose something else :

• No authentication built in (but was easy to setup with next-auth.js)
• No cloud hosting (I would have to host it myself)

Given this I decided to look for something more "out of the box".

Hasura

I was (and still partially am) excited about Hasura. I am a big fan of GraphQL and that is something I was purposely chasing since it would allow me to keep the stack fairly close to my normal working setup. However Hasura does not have authentication, and the docs sounded like a bit more than I wanted to invest on (simplicity). I must admit I might give Hasura a try some day if I do regret stepping away from GraphQL.

Firebase

I have used Firebase in the past, it's pretty nice and very close to what I wanted, however it's not open source and getting data out of it, or migrating away from it, can be complicated. I did this already in the past and don't really feel like going through that again.

Supabase 🏆

Given all of this supabase was a standout. It had basically all the things I wanted :

• Simple
• Cloud hosting
• Authentication
• Open source
• Integration with vercel (bonus)

The biggest letdown was not using GraphQL but given the simplicity I though was well worth the shot. been using it for a while and I am really enjoying it.

Bonus - Vercel subscription & payments starterkit

As a bonus I recently found (and this helped a little validate my supabase choice) that Vercel has a starterkit for sass and subscription projects with already built-in support for supabase, stripe (which I did not included in my choices because I think it's not a deal breaker, but in the only project I am currently charging I am using stripe so its great that it's already there) and also tailwind which is also something I have started trying out recently.

Tailwind was a hard pill to swallow, I must admit, but for this kind of projects I don't need to really have as much of the work on the creative part as I usually want to have. I just need to make something look really good as quick as possible and so I bought a subscription of Tailwindui which is actually money very well spent since not only do I use the components on my side projects, but it works also as a very nice source of inspiration for work.

Find more about this project here

Let me know what you think

That is it! That's basically what my recent process was like to choose what technology to use on new ideas and side projects. If you have some thoughts feel free to DM or ping me on twitter or Polywork

🙌🙌🙌