Daniel Crenna

Code Soloist #12: These are the things you think you know until you do them

You think you can build an ambitious startup* by yourself. The truth is, you can build any number of them that you feel are 80% complete. Turns out, 80% of the business is in the other 20% you can’t do well, or fast, or cheaply. Pareto’s a bitch. You’re better off in terms of expectations if you flip Pareto’s principle around: when you’re 80% done, you’re 20% of the way there.

You think you have both the time, and money, to ship a finished product before that deadline you’re thinking of. This is because the conventional wisdom says that the cost of building a startup in the current technology climate borders on free, with time being the only capital needed. This is relativity, and it doesn’t apply to you, assuming you don’t have a significant source of funds. An engineer-founded startup today still requires cash, in the form of servers and graphic design. The former is cheap enough if you’ve got a full time gig, and the latter varies. But code soloists likely don’t consider the five to ten thousand dollar investment in decent design as ‘bordering on free’, or, they lie to themselves and say that design is a secondary concern. There’s only one of you**, and you need to pay for outside help. 

You think that business book you’re reading is a great book for you, and not just for startup teams with funding and the luxury of unlimited focus. Be wary of the insights from teams. While there’s lot of positivity and energy to unearth in business book classics and new work from your favorite web-slinging duo, you’ll be better off reading these books like you would read a self-improvement manual, with an eye to the future and a casual air. Beyond the criticism that these books largely contain what you already know from experience and social osmosis, as a single developer team, the actionable parts rarely transfer well to your specific goals.

You think you should start with a minimum viable product. The truth is, you need to start, and stop, with a minimum viable business. The product should be small enough that the minimum version of it is all there is. Kent Beck said recently, “Don’t try to do big things. Do little things that can grow into big things”. Taking this mentality at face value, you unconsciously expand your idea out beyond your capacity, and the justification is, you only have to work on one small piece at a time. But that’s revolution, not evolution. The difference is, revolution is never finished, evolution can be what it is for as long as it’s convenient. If you’re racking up experience building whole products, however small they are, the opportunities for these products to evolve after the fact are endless, but if all you’ve got after months of effort are sign posts pointing to some vague concept of a larger product, you’re spinning the wheels. Don’t build small pieces of a possibly big thing, build a lot of small things that stay small. Evolve the winners.

You think there’s no money in a crowded marketplace***. You’ve got more than enough literature to prove that app stores in any flavor don’t bring big profits for nearly everyone who invests in building software for them. Turns out, the world is a lot bigger than an app store, and the same business principles apply in both places. Doing business is hard in any forum. Would you rather try to get the attention of a smaller pool of potential customers with a proven record of purchasing software on your platform, or nearly 7 billion without?

* I consider ‘startup’ here as a term for ‘new business’, but I’d argue that a new business built by one person isn’t really a ‘startup’ at all, and throwing the word around limits you to thinking about your new business as something that needs to grow fast, or be big, to live up to its name. Really, ‘startup’ should be reserved for companies with a board and funding. If you have neither, you’re probably a ‘new business’, which doesn’t limit your thinking at all, or heap false expectations on your plans.

** Contrary to physics, a founder that is simultaneously a developer and a designer, and skilled in both disciplines, is really two people. You can distinguish them from others by the large, conical horn growing from their foreheads.

*** Hat tip to Adam McNamara of Select Start Studios for the conversation that led to this idea.

Code Soloist is for single-person software development companies that are trying to start something big with their bare hands. In it, I try to impart whatever I’ve learned, for better or worse, doing the same thing badly.