Every developer who's had side projects once hit that wall of inability to choose their weapon of choice for their next billion-dollar SaaS idea. The always-returning question being: what stack to pick and how should you approach your project in terms of architecture, testing, and avoiding technical debt? Guess what? Nobody gives a shit.
I've had discussions with other developers about what stack is the best one to work with in terms of building your newest product. Especially if you're building it yourself and do not intend to take anyone else on board. Like myself, others have their biases, considering they've worked with a certain stack. However, if you think about it, 9 out of 10 times it doesn't really matter what stack you pick, and you're probably overthinking and overengineering it.
An old tweet that I commonly refer to regarding the stack of RemoteOK:
Yes, we're all familiar with @levelsio, and some dream the life he lives and some hate to love him; I'm right there in the middle. But there is a reason why he's the OG indiehacker.
No fancy frameworks, libraries, transpilers, transformers, or other forms of overhead that most of the time will only cause you more headaches than it will help you. Some will call him a fool for using JQuery and not leveraging the newest of the newest, but if it works, it works, right?
Every user visiting Remote OK has literally no clue what tech is used behind the scenes, and I bet you a hundo that they don't care. All they care is; does the product performs fast, can this product provide them the value they are looking for and does the product provide that value quickly to them?
Code is just a tool
This can't be repeated enough. Early in my career, I was too much concerned about the quality of my code and the technical decisions I made, and I spent a lot of time learning about how I could improve the overall quality of my code. Granted, learning the difference between bad and good code is important, and when you work in an organization with other people and must comply to certain guidelines and protocol, it's important that your code is on par with that of your colleagues.
However, it is also important to realise that code is just a tool. As a developer, you're essentially a problem solver. Code is just one way to arrive at the solution. When you build a wooden chair, it doesn't matter if it was built using a hammer or a rock, as long as you can deliver the value (comfort) to the person using it. It's OK to write ugly code. It's likelier that your product is going to fail than it is going to succeed, and improving code quality should be reserved for products that succeed.
Haven't you read Clean Code?
Ask yourself this: How many side projects have you given up on already? How many products you've built are halfway there, but you're never going to touch them again?
Was it worth writing tests for them? Was it worth getting the architecture just right? Basically, those projects are now essentially giant lumps of technical debt. It only matters if the product you've built makes it to the finish line, does something, provides value, and is worth working on.
I've learned after many failed attempts that when building your own product, you shouldn't worry too much about how the code looks, worry about unit testing, or overthink structure and architecture. I understand that there are many arguments against this, and it's truly up to you how you like to divide your attention and time.
I'm not arguing that code quality, architecture etc. does not matter. It definitely matters, but it only matters if it's worth worrying about. I'm arguing that in the early stages of your product development lifecycle, you're looking to get something in the field for validation, and in that stage, I personally don't care about code quality. "Good enough" is what you're looking for, and once the product is making that sweet MRR, you can start thinking about improving the quality of your codebase and make iterations that actually matters. It may sound like doing twice as much work, but it's better to do twice as much work for a product that succeeds than to always do twice as much work and waste too much of your precious time.
So what stack should I use then?
Whatever gets you the quickest to the finish line, which in this case is getting a minimal viable product online that you can deploy in the field, iterate on, and validate if your product can deliver value to your potential customers.
Too often, I've taken the occasion of building a new product as an opportunity to try out new tech or a new language, only to see myself burn and want to jump off a cliff while figuring out the little nuances of that new hot thing I'm learning. It's too much of a burden to give yourself while you're trying to realise your idea and considering it's one-man show, you're only going to make it yourself more difficult.
However, if the intention is to learn new tech and the side-project is the carrier to your world of new knowledge, then yes! I completely agree! That's a great way to learn a new language or understand a new framework and a great way to retain that knowledge by putting it in practice.
But if the intention is to get something off the ground ASAP, just stick to your guns, make miles and start pounding.
But seriously, what stack?
I can't speak for you or any other developers out there, and there are a myriad of tools and frameworks to pick from. It essentially depends on your experience and what your background is.
If you've worked in tech long enough, you're probably comfortable with a set of tools already. If that toolkit allows you to build a product today, then there you go; you've got your stack.
If you're new to development and indie hacking in general, then it is important to get your basics straight. I understand that it's hard to navigate through the world of development with people around you holding shiny tech in their hands and promising you the path to nirvana. But if you really looking to start indiehacking through programming, I imagine your best bet would be to get your hands dirty with JavaScript. Purely for the following reasons:
- There are so many JavaScript resources online to learn from, and the community is huge.
- Yes, JavaScript has a lot of little quirks that will give you a pain in the ass. But even so, It's a fine language to start with, especially if your next step is to start learning TypeScript right after that.
- JS frameworks and libraries like Vue, React, Svelte, etc. are very beginner-friendly.
- 2 for the price of 1 if you decide to throw Node and Express in the mix for your back-end server.
- 3 for the price of 1 if you ever want to build a mobile app using Ionic or React Native.
I don't intend this post to be the beginner's guide to indiehacking or development in general. There already are very good ones on this platform alone, but I do believe JavaScript is a solid gateway drug to the world of development.
People are going to argue that there are better options to choose from over JavaScript, and they are probably right. But it has worked for me and it's likely that it will work for you as well.
What do you use?
Essentially, my toolkit is pretty much as follows:
- I use React for building web-based applications. Like all hipster React developers, I commonly use Next.js. However, lately I've been a huge fan of Create T3 for end-to-end typesafety. I've used Nuxt.js in the past but haven't used it in a while, but I'm still a huge fan of Vue, and with their latest V3 iteration, I'm thinking of giving it another shot.
- I use Node/Express for building back-ends using TypeScript (with ts-node). I used to work a lot with MongoDB, but recently switched to PostgreSQL using Supabase. Or host it myself—it depends on the situation
- I use Flutter for building mobile applications. Used to work a lot with Ionic (for side-projects and professionally), but holy crap, I'm so happy I made the switch to Flutter.
- Digital Ocean for all my server stuff. I believe there are cheaper alternatives, but as far as I know, nothing beats the ease of use of Digital Ocean for me.
Don't take this as advice; I'm a student of life and I'm learning new things as I go. But these are the guns I'm sticking to.
I'm very open to hear what everyone else thinks about it, don't hesitate to give me your 2 cents!
Top comments (0)