Bootstrapped Founder #56: Tech Stacks and Indie Hacking

Dear founder,

Interested in listening to this episode? Check out the Bootstrapped Founder podcast here.

David Heinemeier Hansson tweeted about Shopify this week. A lot. He was shining a light on their use of the Ruby on Rails framework, which he open-sourced back in 2004. That sixteen-year-old software powers a business that processed over $100m in sales per hour at peak Black Friday. Not only is Shopify running on Ruby on Rails, but so are Basecamp, Hey, and Github. That's plenty of well-established businesses using long-established technology.

And then, there is Discord. They've been building a highly performant chat platform using Elixir, a programming language that only has seen some mainstream adoption in recent years. While Elixir is stable and is both blessed with a wonderful community, remarkable frameworks, and a substantial amount of open-source libraries, it is dwarfed by the resources and popularity of Ruby on Rails.

So, what is a new founder to do? How do you choose the technology that will power your business, and how do you choose it well? Both Shopify and Discord have selected their tech stacks carefully and intentionally. What are those rules for founders of bootstrapped SaaS businesses?

When in doubt, choose established and familiar technology. Plain and simple. Here's why.

The Best Tech is Established Tech

Building a business is a process of exploration. You start with one thing, and a few months later, you end up with something different. Being able to do all of this without having to switch out the underlying technology is paramount if you want your business to be nimble.

Picking a technology that is a generalist will help you with that. If something has been used to solve many problems before, it will quite likely help you solve your own problems, no matter what they are (or will turn out to be).

Look at Ruby on Rails. It has helped build an email platform, eCommerce businesses, code repository services. It powers AirBnB, news sites, SoundCloud, the Yellow Pages. It can do pretty much everything, and it seems to do everything well enough. This is a generalist technology.

Generalists have two significant advantages: there are many helpful resources out there, and you can quickly find developers to help you with your product. This means you're more likely to find solutions to your coding problems as someone might have run into those before you, and you will have an easier time recruiting an engineer later down the road, as they are easily found and know what they're getting into.

If you pick a battle-tested technology, you will know that thousands of businesses use that stack. Many of them will operate at your scale, whatever it is. Using an established generalist makes sure that your product will be scalable. Even if you run into problems, there are breadcrumbs all over the web, detailing how others ran into scaling issues and overcame them.

Now, compare this to a piece of technology that is currently trending and being hyped. It's quite likely that that tech hasn't been used in production much. You can't be sure that it will allow you to build what you want — it will only allow you to reliably build what has already been attempted by others. For a young technology, that won't be much.

You also won't find many detailed resources. They just haven't been written yet. It's quite likely that you might need to write them yourselves. Unless you have a lot of time on your hands, you probably want to put that time into your business and not into taking notes for other developers. I certainly don't want to be the one running into edge cases for the very first time.

That brings me to specialists. If you pick a language or framework built to solve one particular problem, like time-series databases, be absolutely sure that you won't need it for anything else. I once built a marketplace system on MongoDB, thinking that that database would be a better fit for fast geo-bounded queries. It turns out I could have done this much more manageable and with fewer headaches using a regular relational database.

Picking an established generalist over a fancy new piece of technology is a foundational choice. You want your foundations to be solid. Go with what you know will work.

The Best Tech is Familiar Tech

And that brings me to you, the founder. How do you know what works? Well, you'll know most about the things you've worked with before.

When I picked the tech stack for FeedbackPanda, I went with Elixir/Phoenix and Vue.js because I had just spent two years working for a software company that built a successful IoT product on that stack. I knew how to develop and deploy Elixir/Phoenix apps and how they can be scaled. Any piece of Elixir code would be self-explanatory to me, as I had worked with it for years.

Why would I ever choose to start learning another language at that very moment? Right when I am the most proficient at my craft, why would I swap my tools?

Yet, so many founders see founding a new business as an opportunity to play with a new language or framework. I don't think that's a good idea. It's like an Olympic ping pong player would suddenly pick a tennis racket for the game that matters most: their final match.

Stick with what you know.

There was a post on Hacker News last week detailing the tech stack of a one-person SaaS business. I recommend reading the article about the tech behind PanelBear and reading the Hacker News comments as well — something I rarely recommend. Many founders shared their stories about why they chose the stack they have now, what they learned, and how they'd choose next time around. If you want to learn from real-world examples, that is an excellent place to start.

For the marketplace system I mentioned earlier, I got the database choice wrong. But the framework choice, I got right. Before starting that business, I had been working for a startup that extensively used NodeJS. I had worked with Node for a few years, and I knew how to build and deploy things... sound familiar?

Using the technologies that I knew and was comfortable with removed a critical point of friction from the whole entrepreneurial journey: infrastructural uncertainty. If I know what tech the stack will use, I know what platforms it will run on. Knowing that I can run my product on this stack for a long time allows me to save money by committing to specific infrastructure dependencies such as cloud providers by picking yearly plans or even provisioning services ahead of time. Removal of uncertainty allows for commitment and peace of mind.

I call this the tech-founder-fit. A technology is best for your business if it's easy for you, the founder, to deal with, maintain, and expand when business needs change.

That means you should know the tech before you use it with your business. Learning something new while at the same time trying to build a business that solves a yet-unsolved problem is juggling twice the uncertainty. Frankly, it's a business, not a hobby. You're building to help, not just to learn, and you're not building a little experimental widget just for a portfolio. Learning a new stack takes a lot of time and focus, and all your attention should be on the business. Also, specific problems only appear at a particular scale. It's much better for your capacity to deal with stress and anxiety if you already know what can go wrong and how to deal with it from a prior project.

Many developers and engineers want to "up-skill" to keep up with the industry, to be employable, or just to be able to have conversations with their peers. It's important to understand that you have to "up-skill" in all kinds of fields as a founder. You'll need to understand the SEO tricks of the day, how to handle remote employees, how to navigate this year's sales tax provisions. In all honesty, learning a new language or framework is very likely not the most important thing you could learn. If you already have in-depth knowledge of a particular technology, look for an opportunity to learn something that you are not yet an expert in.

And don't worry if your tech choice is not a perfect fit. If you are looking for anything perfect in entrepreneurship, you won't find it. Make do with what you have today, and get going.

It doesn't have to be perfect. Your initial tech choices only have to allow you to build something that is performant enough, scalable enough, and maintainable enough. If you can get your MVP out with that, you will have ample time to optimize later. Even rebuild your product, if you must. But for now, you want to get going quickly and with something established and familiar.

Because the point of building a business is not "learning a new framework." It's all about getting paying customers for a product that helps people with real problems.

Thank you for reading this week's edition of The Bootstrapped Founder. If you like what I wrote about, please forward the newsletter to anyone you think would enjoy it too.

You can find my book Zero to Sold at zerotosoldbook.com. It is being sold on Amazon and Gumroad.

If you want to help me share my thoughts and ideas with the world, please share this episode of the newsletter on Twitter or wherever you like, or reach out on Twitter at @arvidkahl.

See you next week!

Warm Regards from Berlin,

Arvid