

The Myth of the Single-Person Startup - Aaronontheweb
http://www.aaronstannard.com/post/2010/06/12/The-Myth-of-the-Single-Person-Startup.aspx

======
daveungerer
"... and had him take a look at some of my UML diagrams."

OK, so you give yourself only a month to launch a web-based startup and you
spent some time... creating UML diagrams? I'm trying really hard not to be
snarky here, but that immediately disqualifies you from writing blog posts
about startup myths.

It sounds like you took the development process from your day job and applied
it to your startup. But you're forgetting that these processes were designed
to facilitate communication between larger teams. Which means you've given up
one of the most important advantages of a smaller (even single-person) team.

Also, your version of a single-person startup is a straw man. No-one ever said
being a single founder means breaking contact with the rest of the world.

As a single founder, here's my humble advice:

\- You learnt a lot in this month. You'll learn new lessons on your next
startup, whether you fail or not. Take some time to process it all while you
think of your next startup. Maybe read some PG essays (Read them critically,
the same way you'd read anything else. I'm trying not to sound like a fanboy,
but his essays do have a high insight to noise ratio).

\- Don't for one second deceive yourself into thinking a month of full-time
work is enough. Even if you could complete all the coding in a month, things
like SEO and just generally getting traction take much more patience. You
said: "...get the first core part of my service in working order, and profit".
Know that the road between a working service and profit is very long.

\- If you need a Chief Architect or a DBA to evaluate your technical design
decisions, you're probably not ready to be a single founder. Try to get more
design experience in your job, or team up with someone who has complementary
skills for your next startup. As a single founder, time spent talking to
people means mostly talking to customers, not other technical people.

\- Your article seems to be pretty focused on just development, I guess
because you never even got to beta. You'll have an entirely new perspective on
things once you launch a service and come to the shocking realisation that
customers don't magically appear. Most startups don't fail for lack of
technology.

\- Have you given up on your idea now, before even giving it a chance to prove
itself in the market? Then you had the wrong idea. An idea you really believe
in is one you'll only give up on after serious repeated attempts to get
customers deliver no results.

~~~
erikstarck
Well, some people naturally think better in lines-and-boxes than in code.
Nothing wrong with that, it's like sketching out mockups or wireframes, it
gives you a better overview of what you're trying to build.

It also clearly, like this example shows, makes it easier to communicate with
other techies about what you're doing and how you're solving certain problems.

~~~
daveungerer
What you're saying is technically correct, but misses the point. I also find
it useful to draw lines-and-boxes sometimes, but it's much faster and more
creative if you don't constrain yourself to a standard like UML. The only
reason to use UML in this case is if you intend to use your diagrams as a
communication tool rather than just a thinking tool.

But, as a single founder, you should have no need to communicate the kind of
information conveyed by a UML diagram. If you require that much hand-holding,
you're not ready to be a single founder. Time is a very limited resource for a
single founder, and if you're spending time discussing UML diagrams, where are
you going to find time to talk to customers, create a good marketing pitch,
and all the other things required to create a profitable company?

------
patio11
It has been _enormously_ helpful for me to have Internet peers on the Business
of Software boards, HN, and the like. Having someone to talk to helps with
motivation, practical advice, and maintaining your sanity while doing
something that 99% of the people who know you in real life think is totally
out-of-your-mind bonkers.

~~~
robryan
Except for gauging how a product will resonate with end users if your
targeting a non technical audience, those other 99% can be very useful for
discussing broad concepts or showing demos to where other technical or
business startup people will usually focus on different aspects.

------
jonpaul
I wrote a whole response to this. <http://techneur.com/post/703440900/beware-
anecdotes>

In short:

1) A month isn't long enough.

2) Why did he scrap his code after 12 days? Why did he build UML diagrams?
Sounds like a bit of over-engineering to me. He should have focused on the
MVP.

3) He thought all he could do was code, and then he would be successful.

4) He didn't reach out to potential customers.

People need to read stories like this though. Way too many people fall victim
to these mistakes. I did two times before my third startup. It sucks, but this
shit takes time.

~~~
MicahWedemeyer
Agreed, especially about the need for these true stories. There are all kinds
of startup myths that never seem to die (just get 1% of market, acquired after
6 months, build it and they will come, etc, etc) thanks to the outliers who
get lucky and make for great fairy tales.

------
credo
It certainly makes sense to "stay in touch with potential customers and
clients all the way through the process" and to brainstorm ideas with former
colleagues and friends. (Groups like HN can help too)

However, I don't see any of this as being unique to a single-person startup.
All of this is also true for startups that aren't "single-person startups".

As for "Twelve days into my project I had to scrap virtually every piece of
code I had written - everything. It was a disaster." throwing out code isn't
unique to single-person startups. Larger startups and large companies can tell
you that they've thrown away much bigger efforts :)

------
i386
Did anyone else scream a little on the inside when he said he was using UML
diagrams? I get the feeling he was going for a grand design rather than
shipping something close enough to the final idea that actually works. I think
we have all fallen into that trap before.

------
mindcrime
That's good stuff, thanks for sharing! When you approach things from an
engineering perspective, it _is_ appealing to lock yourself away and "just
hack," that's for sure. In fact, I've been doing a lot of that myself, and
just a couple of nights ago somebody on IRC was sorta-kinda calling me out on
not having other people involved. So I guess I can say - to some extent - "I
feel your pain."

One thing though:

    
    
      Get feedback where you can; talk database schema with the 
      DBA in the break room at your day job while he’s 
      refilling his coffee; share your ongoing startup problems 
      with family and friends who’ve launched businesses 
      before; join online news groups and connect with other 
      people familiar with your problem domain; just stay in 
      contact.
    

I 99.9% agree with that. The .1 percent is the part of me that's reluctant to
talk too much about startup ambitions around the day-job. Depending on the
circumstances, your relationship with your employer, any binding legal
agreements, etc., you might or might not want your day-job people being too
aware of what you're doing in the startup realm.

------
mikecane
I was once discussing how cults were formed with a friend. Most cults revolve
around one crazed person who's the focus of the group's adoration. I said to
my friend: Who was the _first_ member of that cult? _That's_ the guy who got
things rolling. A crank on his own is just a crank. Thoroughly convince _one_
other person and a cult begins. It has to be something like this with
companies too.

------
jrussbowman
Not sure I agree with the title. Sounds like you learned that you can't build
a product from idea to finish and launch a business in a month.

I've rebuilt my project several times over the past year, I've just done it
all in my spare time while working on my job. This has given me more time to
evaluate and think about my changes before making them, and even then it
hasn't always helped.

I do agree you need interaction with others. Right now I'm looking for any and
all feedback I can get on mine. But just because locking yourself in a room
for a month didn't end up you creating your own startup doesn't mean that a
single founder startup is a myth.

------
JoeAltmaier
Any complex task goes quicker with more than one person, simple statistics. If
you are very good, and will only be stumped on 1% of your issues, pairing up
with another founder with the same stats reduces your chances of getting stuck
(or going down the wrong path) to 1 issue in 10000. Your mtbf goes up by
several times! Even if your partner is wrong 10% of the time, you still
improve by 10X. MTBF goes way up, and MTBF is very important in a low-budget
startup.

------
hkarthik
Sounds like you weren't experienced enough with the technology before you went
after a full blown effort to build a product/site.

I'd recommend building some throw away project for fun that might still be
useful to you. That will help you learn what design process works for you and
help you get comfortable with a chosen technology stack. Once you have one or
two of those projects under your belt, you'll be better positioned to start
something more worthwhile.

------
koenigdavidmj
Didn't Gabe (the Duck Duck Go guy) basically say that if you call yourself a
one person startup, then you are still going to depend on community (even
online community, like Stack Overflow or HN) to replace the role that a second
and/or third person would fill?

------
gregn
The boundary of time to work on it doesn't have to be so set in stone. Most
decent startups would take more than just 1 clear-cut month of coding. Just
keep working at it, and working at it. It's the tenacity that's important in
the long run.

------
edw519
WorkingWithOthers is a necessary but not sufficient condition for a start-up.

WorkingWithOthers during start-up = co-founding.

WorkingWithOthers before start-up = experience.

Either method can work.

------
startuprules
Misleading title. The story had more to do with the fact that the founder is
inexperienced and thought he can do it all, not the fact that he is one
person. 5 inexperienced founders also can get nowhere. Flip side, one repeat
founder can create a great MVP in a month by locking himself in a closet.
Perhaps the blogger is also inexperienced at writing articles

~~~
mindcrime

      one repeat founder can create a great MVP in a month by 
      locking himself in a closet.
    

But can he create a startup by himself? A viable one?

Sure, he's got a better chance if it's his 2nd or 3rd or nth time around...
but even so, you have to have feedback at some point... you probably can't
literally (except in rare cases) be a true "one person startup." Even if the
other people aren't _founders_ there are still most likely going to be other
people involved.

~~~
startuprules
if he made the product for himself (solving his own pain), then sure he could.

------
impeachgod
"I grew up with a father who successfully launched his own self-funded
business and made it look easy."

Bullshit, I grew up with such a father and he definitely did not make it look
easy. From the insane time requirements and the difficulties and tricks of
negotiations, I definitely think I could not do it, as a nerdy computer geek.

~~~
chegra
I think he meant his father's cheerful calmness. He probably made the world
seem easy. His father probably never complained, so his sons just didn't know
what problems he might have had.

