
Common Mistakes I See Founders Make Over and Over Again - TheFullStack
http://blog.fullstack360.com/post/134693547565/the-horror
======
jacquesm
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.

~~~
jayroh
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.

~~~
jacquesm
Very neat, you should definitely do a write-up on that, it is super
interesting that you found a way to do this.

~~~
jayroh
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...](https://robots.thoughtbot.com/a-client-project-two-years-later)

~~~
jacquesm
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.

------
qhoc
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.

~~~
keerthiko
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.

