How to Create a Start-Up in 2022 (according to DHH)
Bootstrap and Be Your Own Boss
Before you seek investors - ask yourself - why do you want to create a business?. If you are like David and want to start a business, because you want to create great software on your terms and set your agenda and timelines - bootstrapping and starting it with a maximum amount of freedom and sticking to that is a great way to go.
I wanted not to have a boss and changing an actual boss for a set of bosses that became my bosses because they gave us money was not very appealing. - David Heinemeier Hansson speaking on the alphalist CTO podcast, 2022.
Minimize Risk and Keep Your Day Job
Contrary to popular belief, entrepreneurship is not about risk-taking. It is not a good idea to put all your eggs in one basket. DHH created Bootcamp by devoting 10 hours a week to it - what David had available after working at his regular job.
There's a stereotype of entrepreneurs that like, oh, they just love risk. I found for a lot of entrepreneurs that is not true at all. It's certainly not true for me. It's not true for Jason. We took on zero risk to start our business. We literally started the business as a side project. There wasn't even $200,000. There was no dollars. It was something we did in more or less our spare time. We built it up on the side and we didn't put our eggs in that basket until the basket was strong enough to hold the eggs on their own terms. So we didn't give up the consulting business that we had until the product business was solid. So this is another kind of stool in our advocacy here is that this confusion that becoming an entrepreneur means having a high-risk tolerance is complete nonsense. - David Heinemeier Hansson speaking on the alphalist CTO podcast Episode #45.
How DHH does Product Discovery
Ideal Product: A SaaS for SMEs that you would use
DHH believes that a SaaS product for SMEs is the best product to pick. It's the easiest as it doesn’t depend on virality or network effects. You would need a lot of capital to compete in a market that depends on network effects like Facebook or Twitter. And that funding requires investors which would take away your freedom. It's, therefore, best to start small with a SaaS for small businesses which is the quickest way to a self-sustaining product.
If I were to start over again, I would I'd probably pick something similar [to Basecamp]. Working in [the] small, medium-size business arena allows you bootstrapping in a way that does not depend on virality. It does not depend on network effects.
But just yourself starting a commercial piece of software that solves a problem for small and medium size businesses - you can sign up 10 customers and you get going.You learn something- you sign up a hundred.Now you have something going, you sign up a thousand and you have a business that's self-sustaining. - David Heinemeier Hansson speaking on the alphalist CTO podcast Episode #45.
Why should it be something you would use?
DHH recommends building a product that you are looking for and would pay to use.
I am only interested in doing the kind of work where I have some mode of evaluating whether what I'm building is good or not good. Because it's just so much easier, and then you end up with a product that is compelling to you at least you. A lot of people end up building software that's not even compelling to themselves - they would never have bought that if it was made by someone else. They have these delusions that, oh, I'm, I'm building it for someone elseand if I just ask them (potential users), then they will come and they will pay. No, [users] will not pay. - David Heinemeier Hansson speaking on the alphalist CTO podcast Episode #45
He thus provides his own product validation - bypassing the need for focus groups.
The V1 - the first released version that we do of any product - we built it exclusively for ourselves. Then once we have something real that has integrity and a vision, and we believe is valuable because we would pay for it if someone else had made it, that's the time to hear reactions. - David Heinemeier Hansson speaking on the alphalist CTO podcast Episode #45.
Why doesn't he ask users about what they are looking for?
Avoid pre-programming focus groups. Initial Product features should originate from as few people as possible
DHH believes that having user feedback before the product is shipped distracts the product from its simplicity.
I think if you look at the history of software created by committees - it's usually kind of $h1t. Because you just take all these inputs and if you don't have an internal cohesive vision for where you want to take it - you end up with like the Homer Simpson car. (The Simpsons had this episode where they said “let's ask the common man to design a car” and the Simpsons designs this car and it's an absolute monstrosity with all sort of ideas put together. It’s just crap, right? I think most good products are created, carved out of a singular vision of a tiny team. -David Heinemeier Hansson, speaking on the alphalist CTO podcast Episode #45.
However, not all developers create products for themselves. If you are creating a product and you yourself are not its target audience - then you should involve users earlier on - perhaps in the pre-programming.
The idea of involving [users] early on is a mode that should be reserved exclusively for domains where you don't have any chance of knowing what it's like. You're making software on behalf of other people and you don't have any insight on a personal level into their situation and what they would want. Again, God bless those people [that make software for others]. There's Important work to be done there. Holy **** is difficult. -I would never do that kind of work. I am only interested in doing the kind of work where I have some mode of evaluating whether what I'm building is good or not good because it's just a, yeah, as I say so much easier, and you end up with a product that is compelling to at least you - David Heinemeier Hansson, speaking on the alphalist CTO podcast Episode #45.
(If you work in such a domain, you might want to listen to the CTO podcast about product discovery featuring Marty Cagan) He gives great tips there.
Building a Team (Hint: Keep Small)
One thing DHH has always believed in having a small company.
I think most good products are created, carved out of a singular vision of a tiny team. - David Heinemeier Hansson speaking on the alphalist CTO podcast, 2022.
The more people you have, the more complexity. You simply cannot run a 150 person organisation the way you run a 25 person organisation.
I'd like to delay hiring as long as possible. The more people, the more trouble. (it's kind of like more money, more trouble.).A lot of entrepreneurs think, ‘oh, it's so hard to start a business’. No, it's not. It's not hard to start a business. It's hard to stay in business and it only gets harder. The longer you go, the more people you have, the more customers you have, the more complications. And in many ways, those complications are contrary to the things that you probably enjoy the most. It certainly was in our case, I spend a lot more of my time dealing with a large company versus the time I spent dealing with a small company that the freedom of having fewer customers, having fewer people around is immensely satisfying. That creates this cognitive dissonance when you realize, oh, I'm not, I'm not happier, necessarily running a company of 50 people or 500 than I was company of five. Therefore I would try to find ways that we could stay in the, in the sweet spot, out of a small group for as long as possible.
In fact, in 2014, DHH and Jason SHRUNK their product offerings so they could stay small.
In 2014, we had four major products. All were doing well, but one of them was doing better than the others, and that was Basecamp. We were faced with the choice of either rapidly growing the company at that time to do four products justice, or do the weird counterintuitive thing to shrink the company - shrink the products and shrink the number of customers we had to fit the company we already had. - David Heinemeier Hansson speaking on the alphalist CTO podcast Episode #45.
What was his cut-off point? 50. Once you get past 50 the company structure becomes a lot more complicated.
I knew that once you get to about 50 people or so you can no longer do without layers of middle management. You simply need middle managers that sit between the executive team and individual contributors to be able to scale, to be able to do the people who are working for you justice in terms of what they need in career guidance and management and all these other things. So we didn't want to get into that. - David Heinemeier Hansson speaking on the alphalist CTO podcast Episode #45.
Bigger isn't always better - a small tech team is sometimes ideal
One of the things DHH wishes more tech founders would understand is that there is beauty in being a small business.
There's nothing wrong with running a business of five, 10, or 15 people. It's not a stepping stone to something else. You don't have to apologize. You don't have to act bigger than you are. Embrace the fact that you're small embrace the fact that you have constraints, embrace the fact that you don't have all the money in the world and you will probably end up making unique, better software of it and the world needs those alternatives. - David Heinemeier Hansson speaking on the alphalist CTO podcast Episode #45.
(In an earlier CTO podcast, DHH said the ideal size of a tech team is 3 people).
Product Validation by shipping a paid V1 to users as soon as possible
Until you have traction, all the time you spent on the sort of foundation or technical underpinnings - is time you're not spending figuring out whether you even have an idea that's worth it. - David Heinemeier Hansson speaking on the alphalist CTO podcast, 2022
Most ideas - don't work. Most businesses don't work. The sooner you can find that out the better cuz then you can move on to something else.
[The fastest way] you can find that out is by building real software and delivering it to real people and asking, “do you wanna pay for this?” Or at least, “do you want to use this?” Until you get that validation all the time you spend on the technical underpinnings is wasted. So you want a toolkit that's good enough to get you to that answer as quickly as possible yet will also allow you to go from there to a larger organization. And that is exactly what we've optimized Ruby on Rails to be - the least amount of barriers for you to validate your idea and the full runway to take your idea the whole way.- David Heinemeier Hansson speaking on the alphalist CTO podcast, 2022
This is how DHH sees product validation.
Ship a simple V1 as soon as possible - it's the best way to validate ideas before spending lots of time in the technicalities.
Build a product based on what you want and get ideas from other parties once you have shipped. It keeps the product simple.
User should give feedback on the real, usable V1 (not a Figma prototype)
Validate your product on paying users
Keep the tech simple, use toolkits and low-code where possible. When it's time to get complex, you will have the resources to make it complex.
As discussed earlier, DHH believes that the more people are involved in ideating a product, the messier the product is. The best way to get people's opinions while still keeping the product clean is to present them with a finished product and get their opinions.
Why you should test your product out on real, paying users.
DHH believes you only really know if your product is good if you have strangers willing to take out their credit cards and pay for it. This can only be done on a coded version and not a ‘fake tool’ (e.g. Figma prototype).
Offering people fake tools. [aka Figma prototypes] - I don't think that works. ..You don't get real answers from the market until you actually ask strangers for their credit card. And strangers are never gonna give you the credit card to buy something that does not exist. You have to make something that actually exists, solves a real problem and is compelling enough that strangers - not your friends nor your acquaintances - will get their credit card out of their pocket and enter it into your web app.You need to make something real for that to happen. So I am not a believer in essentially a focus group validation of ideas. - David Heinemeier Hansson speaking on the alphalist CTO podcast Episode #45.
Build a Tight V1
Focus on Core Differentiating Features
We follow the path of building a V1 of everything. Build a tight V1 - not a V1 that takes five years and has all the belts in the whistles. Build a V1 that's focused around the epicentre of the idea - the core kernel of why this is unique - why someone would wanna pay - and why they would not wanna go back to whatever they were doing before once they've experienced your piece of software - David Heinemeier Hansson speaking on the alphalist CTO podcast, 2022
If you want to transform an aspect of people's lives focus on the core change and don't get distracted by offering features just because competitors have them. Once you release the V1 you will which features were truly missed and which ones are unnecessary. By putting all your efforts into the core benefit of your product, you can get a good yardstick of how transformational your product is if customers don't want to look at their old solutions after that.
That is what DHH did with Hey.
When we rolled out, Hey.com it missing all sorts of baseline features that many other email clients had because we were focused on the things that made us unique. And then we got feedback. What were most of the things we arre missing? What's the most important? What's preventing someone from using Hey? We learned a ton from that feedback. But if we had started there, like, ‘what do you want out of an email client?’ And we'd interviewed a hundred people. We would've ended up with the Homer Simpson car of email clients, an absolute monstrosity that no one would've wanted to inflict on their worst enemy. - David Heinemeier Hansson speaking on the alphalist CTO podcast Episode #45.
Choose the language you are most comfortable with (they all scale if done well)
Choose the language that fits your brain. If when you think in code you think in Go - then use Go. For DHH, Ruby was the unlocking technology that enabled him to build Basecamp - and he has happy for everyone else who has this eye-opening experience no matter the language.
However good [Rails] is - it's not gonna be the thing that fits most people's brain, because nothing does. We should be having an ecosystem of choice where someone goes like, ‘Do you know what? Go really just fits my brain. This is the language. When I think in code, I think in Go’ and I go like, ‘oh my god, I'm so happy for you. I'm so happy that you found Go and that fits you because this is how I felt when I found Ruby. That Ruby was this unlocking technology that enabled me to go from mediocre PHP programmer to building something of real sustaining, lasting value with Rails, with Basecamp, with all the other things we built. Because Ruby unlocked that in me, I would want for everyone to find that unlocking technology or ecosystem for them. And there's never gonna be one that works for everyone. - David Heinemeier Hansson speaking on the alphalist CTO podcast Episode #45.
Stop agonizing on language and focus on the architecture and coding.
Do all languages scale well?
Any language can scale if utilised well. People like to blame PHP for Friendster’s demise but Facebook is built on PHP and it managed to scale well. Friendster got killed because it probably had the wrong architecture. (It's easier for developers to blame the tools…). People used to say Ruby on Rails would not scale - yet look how Shopify and Github managed to achieve with it.
Almost all the modern tools, whether you think of JavaScript or Rails or Python or PHP, are able to take you all the way from Zero to Facebook if you have the right architecture. The right architecture [being] to some extent a function of ‘do you have competent people who understand the problem space that you're dealing with?’ - David Heinemeier Hansson speaking on the alphalist CTO podcast, 2022
(For definitive guidance on this topic, you might enjoy this article about choosing a language for your web application (NodeJS vs PHP vs Ruby) by alphalist CTO member and podcast guest Fabian Wesner).
Architecture - focus on real user needs - not what is trending (SPAs etc.)
Don’t Overcomplicate your tech stack. Your goal should be to ship the V1 to customers as soon as possible - and all other versions as soon as possible- with the smallest team. You should focus on what users need and not what's trending in the tech world.
You probably don’t need a SPA.
SPAs are hot now. Yet do users need it? Amazon is not a SPA and no one complains.. Hey.com is not a SPA and it shipped as 30 kilobytes of Javascript as opposed to Gmail’s 4.8 Megabytes. Even though no one thought an email client with it’s high UI fidelity needs could be achieved with so little javascript and not as SPA - yet Hey.com did it and it has millions of paying users thrilled with the flow. SPAs complicate things a lot.
I actually think that the complexity of the sort of Single Page Application and so on is barely mitigated by the fact you used the same language on the front end and the back end. It'll be a lot simpler, right? That hypothesis was proven false. It did not get simpler. Get it got horrifically complicated to the point which totally gets us away from the idea of the one person framework that one individual could build it all without having to study for 20 years to learn all the intricacies of it. And I think there is a growing sense now that people realizing, ‘why is it that we're creating features so slowly?’, ‘ Why is it that my team need to be this big before we can make any progress?’ ‘Aren't there better ways of doing it?’ ‘ Why are we complicating ourselves into such a corner that it now takes this huge team to do these basic things? We used to be able to do five minutes ago with one person. And that's the idea that we've been pushing with Rails seven and Hotwire. That there is a way where you can integrate the whole thing, make it feel holistic, not dualistic, not splitting things up in a backend in a front end, but making it feel like it's one application, it's one code base with as little JavaScript as you can get away with. - David Heinemeier Hansson speaking on the alphalist CTO podcast Episode #45.
Is it easier to create a startup in 2022?
It is easier to create a start-up in 2022 than it was for DHH in 2003. You have access to more productive tools and many of the barriers have come down. That doesn’t mean that it's easy to be a success. It's never easy to succeed. But your odds have improved. Especially because you have read this article in which DHH shares his ideas about bootstrapping, team size, product discovery, product validation, and a variety of counter-intuitive tips on creating a start-up. Now you know not to quit your job to focus on your startup, why you need to validate your product on paying customers how to get a V1 in the shortest time by using toolkits and low code.
