The Myth of the Single-Person Startup | Hacker News Reader

The Myth of the Single-Person Startup

aaronstannard.com

62 pointsAaronontheweb26 comments

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

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.

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?

This is sound advice for any startup, not just 1-person shops. Wish I could upvote a couple more times.

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.

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.

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.

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.

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 :)

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.

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.

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.

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.

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.

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.

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?

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.

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.

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

I was going to say the same thing. Its not about being a single founder, its about experience. I knew what to do when I started my startup. The people I employ ask me questions. Its all because I have spent considerable time learning my skills beforehand.

Eh? The first version of Facebook was created by an undergraduate in 2 weeks. Web startups are just websites, people just blow things out of proportion. You're not working on the Manhattan project, just a website.

In one month in closet, people can create their own OS. In fact, best CS programs force you to.

  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.

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

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

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.

I don't think you know his father well enough to pass judgment.

Reply on news.ycombinator.com