Ask HN: How many startups fail because of code base issues? How many startups will fail as a result of having poorly written code and as a result it prevents them from growing when they need to pivot the most? |
Ask HN: How many startups fail because of code base issues? How many startups will fail as a result of having poorly written code and as a result it prevents them from growing when they need to pivot the most? |
However, if you don't have traction, having poor-quality code can make it impossible to add the necessary features/bugfixes that get you there, and can make it impossible to attract and retain the engineers that can do that. I worked at a startup once that died from this; we had a product that our one salesperson had no trouble selling, a prototype that worked great at demos, but we couldn't make it robust enough to launch a v1.0 that we could in good conscience charge for before running out of funding.
However, if you focus on writing good-quality code, you are not focusing on the product, which also will prevent you from adding the necessary features, polish, whatever that will get you to traction. I founded a startup once that quietly died from this; it had a pretty innovative architecture and a relatively clean codebase, but wasn't really useful for users because I spent too much time refactoring and not enough building & polishing.
Basically, you have to realize that you're gambling. Your goal is to put a usable product on the market. Every bit of code you write gets you closer to this, but also increases the difficulty of writing further code. Every bit of time spent refactoring makes it easier to write further code, but is time not spent improving your product. If you spend too much time writing features and never clean up code, it becomes impossible to deliver further features. If you spend too much time refactoring and never deliver new features, you lose out on the market to other companies that were willing to play a bit more fast and loose. Wisdom is figuring out a balance between them.
What happens is your engineering talent--if you have any to speak of--starts to get really pissed off that they've had to repeatedly cut corners and now are being expected to save the day. This causes lots of stress, and the more experienced the engineer the more likely they are to either ragequit or make large compensations demands. It's not that the cutting corners is what bothers them...it's that the other folks so badly misjudged the business that the cutting corners was ineffective.
Alternately, a competitor is able to look at your product, build a better architecture, and just plain kick your ass because it's more extensible and they can ship faster. I don't have any good examples for this offhand.
As nostrademons points out, though, you can get farther with a good sales team and a shit codebase than with no sales and a great codebase. Lots of examples of that (including my previous startup).