Developers initially assume that choosing the right technology stack is the most important decision to make when starting a project. Spoiler alert: it's not (with a few exceptions). Before you freak out, let me explain why. I'll even use examples from my personal projects, so you don't think I'm some guy from management sitting on a high horse that wants you to use PHP for the next mars rover mission.
A tech stack can be described as a summary of tools, frameworks and programming languages a particular project or product is using. Some prominent examples include the MEAN-/MERN-/MEVN-Stack (MongoDB, Express.js, Angular/React/Vue, Node.js), the classic LAMP-Stack (Linux, Apache, MySQL, and PHP) – for those, who have graduated from college in the previous century – and, more recently the Serverless Stack (Language X + Firebase/Amplify).
Really, a stack can be anything you want. You can build a stack with jQuery, HTML3, Visual Basic and a server in the form of a pizza-oven. In all seriousness, developers sometimes prefer using a relational DB in their ME(X)N-Stack, and that's ok. As long as it fits your need. And this is where the main statement comes in.
How your tech stack slows you down
Developers tend to over-obsess about the technology they choose for a certain project. They factor in scalability and maintainability, and all these other factors, when they haven't written a single line of code. Yes, this might be important if you're building projects for big-ticket clients at a software boutique. But I bet, if that's the case, you wouldn't be reading this article. Chances are you are a solo developer, or even a bootstrapping founder, wondering which database system is the best to use with that SaaS idea, that you have had in mind for the past month.
Here comes the truth: it doesn't matter. The more you think about it, the more you'll be behind on the most important metric in building a business: progress. This obsession with ever-emerging and changing technologies (especially in web development) can be toxic and keeps you – day by day – from just taking action and starting to code. The goal is to get going , not to make the most performant software in the world (again, every rule has an exception).
Your only goal as a developing founder should be to get your product in front of people ASAP. The emphasis is on the "as soon as possible", because it won't matter if your product scales well – if no one will be using it.
Take a look at the MVPs of billion-dollar startups like AirBnB or PayPal. They weren't great to look at and probably performed poorly in a technical sense, but they acquired customers anyway. Customers – not great tech – are the lifeblood of all companies. Facebook was hacked together in PHP by Mark Zuckerberg during a couple of all-nighters at the Harvard Dorms. He used a toolkit he was comfortable with and just threw down code line for line until the first prototype was complete.
How to cure this obsession
When building a product as a developer, focus on what concepts of programming and languages you're familiar with and good at. Again, time to market is the only measurement you should keep in mind when building a product, especially when working a one-man-army job on a project. It's ugly? No worries, get traction – perhaps acquire some capital – and hire a UI/UX designer. Or teach yourself design.
I know it's not 2005 anymore, and you can't get away with having a site that looks like it's been collecting dust since Y2K. But that doesn't mean your SaaS should strive to win design awards either. As long as the product serves its purpose and you can find customers, they will be satisfied with an "ok" look. Form follows function.
The same concept applies to performance. Maybe your database isn't scalable, but that is not something you should have to worry about before serving a million customers or more. Hopefully, by that time your business can hire a database engineer to fix that.
Most SaaS-sites you can see evolving right now can probably run on a single Digital Ocean instance or some budget AWS equipment. Heck, nowadays people are making tools on Low-/No-Code platforms that are used by numbers of users exceeding 100k.
How I escaped the tech stack rabbit-hole
As promised I wanted to share some personal experiences with this. Back in early 2020 when I was just drafting my bachelor's project Jamfony (more on that in the future), a social media platform, there was a million different tech stacks to choose from. Unlike very proprietary fields like embedded programming, web development offered a wide variety of tools you could use to build a platform like this. And with endless possibilities comes the agony of choice.
I was already familiar with JavaScript and PHP from working several part-time jobs in the past, but I was convinced, that the best technology to be used would be Ruby on Rails due to so many similar platforms adopting this widespread framework. So I took an RoR course, read docs and tutorials. I spent a month (!) trying to teach myself the ins-and-outs of this language before ultimately deciding it was too weird for me and not the server architecture I was looking for. Then I spent another two weeks reading Laravel doc before ultimately deciding I wanted to build a PWR and using something that "antique" (in my eyes) would be out of the question.
In the end, I learned React + Firebase which took god knows how long to really get right. I was fortunate enough to have started so early, that I could finish the project on time (while working all week on this project for months...). Most of the learning has been on the go, which is great – as long as you're not short on time and able to live on student grants. If you're founding and living on savings, maybe not so great.
Takeaway
All I really wanted to say with this (stream of consciousness) article is, that you shouldn't worry too much about the distant future means of technology, when all you should be focusing on is the "build, test, iterate" cycle and getting your product in front of (potential) customers as soon as possible. Technology is all cool as long as it's not keeping you from taking action.
Top comments (1)