In other words, technical debt is not a bad thing (just humbly apologize for it later).
And regarding building a startup by yourself, I'd like to expand that to never build a network-related startup by yourself. That is, if...
value = k2 * users ^ 2 + k1 * users + k0
never build a product where k0 = 0 or close to it by yourself. This means, for example, if you're by yourself, build an indie game where you jump on platforms, but never attempt "facebook for dogs". This is because you can't get customers to pay $ for no value, so building social networks without an extremely strong initial user base in your pocket (which, unless you're a celebrity, you don't have) is the tech equivalent of buying the lottery. In a lot of ways, social network features on an app is like legal - if you need to worry about it, you've already gotten to the point when you can delegate an employee to do it.
This is important for many reasons, but the least of which is that there's too little written on what goes wrong with a startup. Everyone (especially the media) seems to think that every startup becomes one of the billion dollar darlings that saturate the news.
My take on the overall concept was that it was going to be really hard to pull off, because you were building a two sided marketplace. And that's exactly what airbnb is (which is why it's appropriate you called the startup an airbnb for cameras). Even if you had you perfect execution and built a product that was 2x better than anything that existed, getting a two-sided marketplace to work requires an extraordinary amount of luck, marketing, and timing.
The flipside is that once a two-sided marketplace exists, it's really tough to displace (for exactly the reasons that it's so hard to start). So I would have loved to hear your rationale for thinking you could overcome the odds of building a two-sided marketplace. It's twice as difficult as a normal startup because you need both the sellers and the buyers. And one is not valuable unless the other is there at the same time.
We do this at my company when we add a new feature that we are not sure will take off. You can get something running quickly that looks good enough to the customer, but behind the scenes is all smoke and mirrors. Then if the amount of traffic starts to grow you start putting in your automation.
It's really hard to resist the urge to build out all of your automation, scaling, etc up front. But, most of the time the new feature goes unused and it winds up being a waste of time.
By definition, any engineering on a failed project is "over" engineering. But there are certainly some projects where investing in a little more development at the beginning will have a greater payback later.
Lack of risk subsidizing never stopped craiglist or airbnb (in its early years). If people want something badly enough they will figure out their own way to deal with the risk.
Having a good cofounder is probably better than not having one, but there are tons of successful products and companies started by individual people.
If the market is busy kicking your ass, a little positive encouragement can be helpful. All startups are really tough at the beginning, and this one never made it out of that stage. But if it had, this rule would probably be the opposite. Also if you want some critical opinions, just try to raise money.
Certainly after an failed startup it makes sense to look back and try to figure out what went wrong, but you also shouldn't overfit. I realize the medium of blog posts does reward overfitting and making rules, but the real world is much more nuanced.
Seems like a lot of obvious things no? I agree it's a lot harder to spot when you're in the middle of it all, but in terms of material for a blogpost, these "learned lessons" are pretty common/generic, right?
How would this be different from, say, "don't forget to file your taxes or you'll waste a lot of time if you get audited". Do you really have to go through an entire failed startup to learn these "lessons"?
Some of the other better postmortems out there have rare insights like "don't talk to corp dev they have an incentive to pretend to want to acquire you to waste your time and distract you", or "don't be tempted to expand to too many geo locations too early or you'll be stretched too thin". Lessons that would be hard to learn without actually going through a startup yourself. Compared to those, the lessons here seems...generic
Sorry maybe I misunderstood. Can someone whack me in the head and bring me back to reality? Maybe it's just me...
He's speaking to engineers who want to start a business. They frequently start by focusing on the engineering things and not on the things that matter to validating their idea is buildable and scalable in a business sense. It's easy to think "we're going to be in a world of hurt if we don't (have automated testing, pick the right framework, design for scalability, handle complicated edge cases, get the design right, etc)."
Engineers will often focus on these aspects while missing the bigger problems like "will the people telling me this is a good idea write a check right now to get it?" and "what non-technical roadblocks have I completely missed and won't be aware of until I'm iterating with customers?" These don't seem obvious to people who haven't been in the business of selling something before. And launching with half-baked crappy hacked software goes against every instinct of a good engineer who has worked at more mature companies.
Starting a business is about finding out, as quickly as possible, if anyone actually gives a shit and then building a business after you have determined that, yes, they actually might. The actual act of making the product feels like building a business but it is not.
It's incredibly easy to get lost in the barrage of objects. Articles like this one help founders refocus and figure out what's important and what's not. Many things seem obvious in hindsight that are completely lost in the present.
Yes I absolutely agree with that. Maybe the 7 "lessons" in the article are not the real lessons--the real lesson is, as you said, focusing on the right/important items.
Also, I think point (3) in the article qualifies as something that would have been difficult for the writer to learn without going through a startup.
I would say, though, advice like "not choosing a confusing name for your startup", seems, well, obvious, no? I definitely respect the guy for starting his own company, but not sure how I should feel about someone who can't even choose a non-confusing name for it...
Don't canonize startup founders. Many of them have no idea what they are talking about, even the successful ones. I'm not saying the OP falls into that bucket, but there is certainly no reason to dismiss that notion outright. Your description of startup life also is just your own experience, it doesn't apply to everybody and you have no reason to believe it does.
1. Little to no customer development
2. Lots of over-engineering
3. No co-founder when they'd actually need one
The biggest mistake this guy made was quitting his job BEFORE validating whether there was demand for his idea or not.
it's easy to let yourself think you know the market instead of asking it (mistake #1), because marketing research is a hard, ambiguous process, while coding is at least logical and the path (may seem) more obvious (mistake #4). and while you're in this bubble, you need encouragement (mistake #7) to keep you going, especially as a single founder (#6, arguably a mistake). these are all mistakes i've made too.
the statement i disagree with is "I'd like to think I got a very cheap MBA along the way." it's unlikely the author got much of that, since in most cases mba's learn much more about running an existing business (accounting, financial projections, etc.) than starting a new business. to be fair, there is, at the core of an mba program, a theme of making decisions under ambiguity and trying to bring as much concrete information into the decision as possible, and the author may be referring more to that aspect. in any case, building your intuition for good decision making requires learning from your mistakes (like other talents).
This article kind of resonate with me. I have a great product that is being used by hundreds of people everyday and I get constant requests for iOs/android apps. If I had more time I would learn how to make a phone app and I would monetize it...
This is an easy trap to fall into. While not bad advice, because its easy to overbuild - sometimes polish is what gets you to success. If slack built just the bare minimum and didn't flesh things out thoroughly, they would not have been nearly as successful.
Thanks for sharing your experience.