I know that many folks out there (including you, don’t lie) are dreamers. You want a creation that not just makes a difference, but is yours. You could make something, put out your shingle, and let people pay you money for it.
Most of us will fail in that ambition. Certainly I have so far. But now that I’ve managed to build a complete product I thought I’d capture some of the lessons I learned along the way. This is probably most useful for “bootstrapped” tech startups, not big companies or lemonade stands or coffee shops, but who am I to stop the friendly reader?
Are you a developer? If not, become one.
Lots of people, particularly those that went to business school (sorry, I can’t help but poke fun), think that creating a software business is as simple as writing down a good idea and merely getting an engineer to build it. Hint: there’s a reason that the number of successful software businesses started with Upwork contractors is approximately zero. If cash could reliably be turned into good software then you could put the venture capitalists out of business. Just sit in your room and meditate on ideas, then spend cash to hire software engineers to build them. How could you lose?
Instead it’s more common for the engineers to have the ideas, start to build them, then come to the VCs so they can grow faster. Instead of coming up with the ideas, the non-technical folks usually help manage existing products or offshoots, not build new ones from scratch. There are exceptions of course, but the successful entrepreneurs tend to look a lot more like “engineers who have business ability” than “business people who hired engineers”.
Why is that? I suspect that while many folks can build a solution to an arbitrary problem, they vary quite widely in their ability to define the problem well.
Know your stuff - create a circle of competence
Building a product in software is an exercise in knowing where to deep dive and where to be satisfied with reasonable defaults. The types of decisions you make on the fundamentals (what language & framework, do users need to be logged in to try it, etc) actually end up changing the user experience dramatically.
Let’s say you aren’t an engineer. The problem isn’t that you aren’t smart enough (you probably are - this stuff isn’t that complicated) but instead that you don’t even understand the paradigm by which you’ll be making decisions.
It’s like trying to bake a cake without going into the kitchen. You can’t ask for vertical lines instead of horizontal ones, without profoundly changing how the whole thing is built!
As you might expect, one circle of competence for a company building software is the building software part. The market pays for outsize value - something a lot of these no-code based companies don’t realize. Yes, there’s a lot of lego blocks out there which you can assemble together, but the real value you’re selling is the glue between those blocks. And since the glue is made out of software too, you still need that body of expertise.
For the software engineers, I have a dose of reality for you too: in my experience, businesses started by engineers sometimes suffer the opposite problem - they are technically interesting, but not worth paying for.
The amount of engineering time being spent creating new programming languages, or writing new javascript frameworks is astonishing. Building something with a different developer experience but no user-facing impact means you don’t have anything to sell. You’ve improved the ecosystem but haven’t actually put food on the table. And indeed, many of these creators, despite the value they’ve provided, are still living off of Patreon or Kickstarter. And while it might work for some, others are still struggling.
You don’t just need a circle of competence in software, but one in the area that you are trying to innovate in. If you’re making software that creates bingo cards, you have to understand that your users often search for dolch sight words. It’s the combination of the two areas that actually make your product rare and valuable.
Find the time.
A lot of people look at me in wonder when I describe building a product while working a full time job. Don’t you already have too much to do? Do you not have a personal life?
Paul Graham goes as far as to suggest that working on other things would lead to your startup’s death. It has now become quite common for people to leave high paying jobs to start companies, but often they don’t really know what company they’re starting, or why. Starting a company has become a kind of personal exploration in which, at the end of it, even if the startup doesn’t succeed, it’s okay. The specifics of what you learn are never very clear, but people seem to be pretty happy doing it, so I hesitate to criticize.
That said, I think the approach is flawed. Many of the best companies were started as side projects, and that was before all of the swanky libraries and deployment infrastructure that is in common use today. I think the startup world is under the impression that you can only build something productively if you’re working 60 hours a week on it. Why 60? Why not 30? Why not 10? Isn’t one 60 hour week just a month and a half of 10 hour weeks? More importantly, can we build something in 10 hours today that would have taken 60 before?
I suspect that while startups can move faster, at least in calendar time, working all day every day, they actually move far less efficiently. That is, little old me on a 10 year old Macbook pro, working solely in the hour before breakfast on weekdays, can simply outlast a sprinting rockstar programmer working for 100 hour weeks on ramen and coffee. That’s the real benefit - the rockstar programmer is dependent on finding someone to invest in him or her, has to find product market fit within a short amount of time, has to figure out hiring and legal and incorporation, etc. Because it’s just me, I only have to do the first one.
Classic software entrepreneurs are busy trying to “build a plane while flying it”. And as glorifying as that might seem, the plane you build is probably worse than it should be. Meanwhile, I’m happily tinkering on my own plane, and I have infinite runway because my day job pays all of my expenses and more.
Prove your grit as an entrepreneur by starting your company while you’re working. Find the time. Depending on who you are, that could be late at night, early in the morning, during lunch, etc.
Maximum power in minimal lines of code
The main value in being a solo entrepreneur is that you don’t have any of the overhead that happens at larger companies. The main downside? You don’t have any of their resources either. Large companies like Google have amazing stuff they never release to the public, so writing code there is always going to be so much more joyful than writing it on your own. You get a sweet developer environment, can provision boxes on your own, and there are massive departments dedicated to looking after you. Of course you have the catering people, but also the operations people, the tools people, the product people, the design people, etc. Even if all those folks are dunderheads (which they aren’t) you’re not going to be able to replicate it solo.
They’re fabricating steel beams over there, and it’s frankly far beyond your capacity. Don’t try, or you’ll get stuck TIG welding a corner piece. You’re building out of papier maché. It’s cheap, it’s soft, it’s easy to adjust. No, it probably won’t scale - but if you have too many users, you’ll figure out how to deal with that problem (and it’s hard even with steel beams).
Your main weakness is you only have 5 hours a week on this project, and Google has, effectively, millions. But your strength is that you can do things that Google can’t. Remember those open-source lego blocks that were in the wild? You can use those in a way that Google never could, because they fully meet your needs and then some, whereas virtually everything in the open source world (including Google’s own open source contributions) aren’t good enough within their ecosystem. At least, not by themselves.
So your job isn’t to reinvent the wheel better than they can. It’s to cobble together a few spare parts, and see if your little local entropy reduction is worth more than it cost.
Build vs Buy? Always Buy.
This kind of goes with the last one, but I’ll say it more explicitly. You should be spending your innovation tokens as carefully as possible when starting your own project. And those tokens probably should be spent on the things the user cares the most about, and not the other stuff (i.e. the user does not care about your dry cleaning).
Here are a few things in the dry cleaning category (which you should almost certainly buy, unless it’s the core competence of your business):
- Deployment infrastructure
- Company email addresses
- Marketing emails
- Blog
- Payment infrastructure
- Databases
For a fellar starting out with a business the size of a beta fish, this stuff should cost less than your weekly date night. Remember that much larger orgs are using this infrastructure too, so you can always tell yourself that as a way of resting easy, and leave whatever special snowflake features you have in mind for your ideal system to your imagination instead of holding up your product development.
Cut scope
Software is an interesting thing, because you can change the problem more easily than you can change the solution. That means you can make life really hard for yourself by being too ambitious and wanting an app that not only solves the user’s problem, but also cooks their dinner, turns on the Al Green, and gives foot massages. Eliminate the excess. The reason why is not because you don’t want to delight the user. You definitely do. But it’s better to have a pretty good solution to one problem than a half solution to 10.
Practically speaking what this means is that you’ll build something that kinda works, and you’ll debate between doing some housekeeping that is absolutely necessary (completing your payment infrastructure, for example) or adding feature Y. Always do the necessary stuff first. Then ship it. Most of the work is after you’ve built the product, after all, and your time is too limited to spend on features that aren’t absolutely necessary. Those 5 hours go by pretty quickly.