8 comments

[ 2.9 ms ] story [ 30.5 ms ] thread
1) Build Build Build

The MVP is a pretty well established item nowadays, this was much more true in the past but people have caught up to this long ago.

2) Fully Outsource Development

No start-up that I'm aware of would outsource all of their development, in fact, I don't recall a single time over many years of a start-up that outsourced any development at all. Are there many examples of such start-ups?

3) The wrong technical cofounder

This I've seen. But I've also seen: the wrong person for sales and marketing, the wrong person for the CEO role, the wrong person for finance and so on. Start-ups are risky in part because there is a chance that one of the founders will not work out and that could easily kill the company if not detected and contained early enough. But that goes for any role, not just for the technical lead, and not more so for the tech lead than any of the others.

4) Spend, Spend, Spend

For that you have to have money first and most start-ups never get to the stage where they do and the ones that do usually have a bit of supervision on that account once they get the 'big bucks'. During the .com boom this was different but nowadays start-ups are a lot more conservative when it comes to their spending than in the past.

All in all this essay would be more applicable 16 years ago than today.

There are common mistakes that founders make over and over again but these aren't as common in my experience. Maybe that's a geographical artifact.

A couple of common mistakes that I do see: failure to communicate clearly and often between founders, failure to accept responsibility, culture of blame, lack of preparation for changing circumstances, lack of proper definition of expectations, founders being in different phases of their lives with different risk profiles, NIH, trying to be both a platform and an application on that platform and so on. These I've seen, recently, and more than once and each and every one of those has the potential to wreck a start-up, even in a later phase.

Re #2 - fully outsourcing development. I've seen this done successfully and as a matter of fact I was on the team that built the first MVP. I'm sure it's the exception and not the rule but it can be done if the team that's brought in is super professional and talented. (We were). There are some benefits to this route if done correctly

1. The code left for the eventual, internal, team is pristine, well written, scalable and easy to jump into. 2. Well defined processes are in place. 3. Our company helped find, introduce, and often interview the new employees for our client.

It's worked out well several times but it's certainly not cheap. You get what you pay for.

Very neat, you should definitely do a write-up on that, it is super interesting that you found a way to do this.
A former coworker did a write-up and an interview with one of his former clients and I think it sheds a lot of light on how this can work - https://robots.thoughtbot.com/a-client-project-two-years-lat...
I've been reading that for an hour or so now, you could easily get another 'Soul of a new machine' out of your project. Maybe not as dramatic but that project could easily serve as a benchmark of outsourcing done right. I'm going to sleep now and I'll re-read it tomorrow. Thank you very much for that link.
Are you available for some questions? If so could you shoot me an email? (jacques@mattheij.com)
One common mistake is: having too much passion and refuse to pivot. This is somewhat a grey area. First, your idea might not be even new and there are many competitors or alternatives (which is more dangerous than direct competitor). Then you end up convincing yourself: yeah, I will be the next Dropbox. Their idea ain't new. Second, even if it is a new idea, you tend to see many problems along the way in term of market adoption. You refuse to change / pivot. You will fall into the circle of denials because you think your product is not up to the mark yet.
There's actually a commonly repeated lesson there (although I forget the popular source) -- You should have passion for the problem, not passion for your solution to it. If you're passionate about the problem, and it's a real one (it's unlikely you can be passionate about an imaginary one), there's no such thing as too much passion. If a solution you worked on for hundreds of hours isn't the right one to solve the problem you're passionate about, that passion will overcome your attachment to the solution and you'll be willing to pivot.

Have passion for the problem, and even if other people have attempted to solve it, your passion will help you solve it better than them even.