An unfortunate truth of solo/duo entrepreneuring is that things get created and written quick and dirty. You simply don't have the time to do everything by the book, especially when you're nights/weekends.
Getting to the point when you have to do a massive refactor is, in a way, a mark of success because it means you're growing and have a good customer base.
You can and should build a big codebase (as far as early stage startups go) without doing things quick and dirty. The additional time is an investment that will save you far more time down the road.
this only applies when you "know" that what you're building will stick around. If you are quickly iterating on an MVP it's more likely that code you write is going to need to be totally revamped.
Acquiring tech debt in an early stage startup often results in never having to pay back that debt
Not true. In the case that your MVP is actually worth something, you don't want to be spending all your time paying off tech debt when you could be focusing on growth.
Would you rather have a well-designed flop, or a poorly-designed hit that you can't scale fast enough?
Remember Friendster from 2003? It's quite possible that it would have not lost to Tribe/Myspace/Facebook if it didn't take minutes to connect before eventually timing out.
There are things that are worse than wasted effort, and one of them is a hockey stick that slips right through your fingers. By the time the curve is inflecting, if you can't keep up, you're burning customers and inviting competition. If you have to rewrite at that point, you are going to lose to competitors with deeper pockets and no PR baggage.
Would you rather have a well-designed flop, or a poorly-designed hit that you can't scale fast enough?
Poorly-designed hit any day. Was this a trick question? :-)
(Obv, I'd prefer a well-designed hit, but I'd rather move fast and validate my market with a hack, than spend too much time and energy building something good that'll never be used.)
Poorly-designed market-hit is usually easier and more straightforward to fix than a well-designed market-flop.
I'll take the market hit any day! (Anyone remember the fairly pervasive "fail whales" along Twitter's bumpy evolution? Did they negatively impact the end state of the company?)
I do remember those, and iirc it almost sank the company. In fact I think that it absolutely impacted Twitter negatively, because the way they got through it was with massive investment in engineering funded by venture capital. So now Twitter is overcapitalized and beholden to be a size that makes that investment worthwhile, and can't make lean decisions that would be better for the world while also being sustainable for itself.
Let's ask ourselves, as either stakeholders or users of Twitter or participants in the culture borne of Twitter's poorly-designed success: are we happy with Twitter's arc?
I would rather have a Basecamp level of success that was well-designed and sustainable. And you don't get there by putting out a pile of shit and hoping for a runaway hit and then scrambling to raise billions so you can backfill everything you neglected to think about in the first place. The only ones who want that are VCs and the hyper-ambitious entrepreneurs who would rather have a billion dollars than make the world a better place.
Assuming you're building the correct thing. Small/early start up mode is about finding product market fit. The additional time is a waste that might never be needed or used. That additional time may also sink the endeavor. Regardless, no sense in beating yourself up and worrying about 20/20 hindsight. Software development produces two things of great value. Working software and information. Know what your current primary production goal is.
Comments
An unfortunate truth of solo/duo entrepreneuring is that things get created and written quick and dirty. You simply don't have the time to do everything by the book, especially when you're nights/weekends.
Getting to the point when you have to do a massive refactor is, in a way, a mark of success because it means you're growing and have a good customer base.
You can and should build a big codebase (as far as early stage startups go) without doing things quick and dirty. The additional time is an investment that will save you far more time down the road.
this only applies when you "know" that what you're building will stick around. If you are quickly iterating on an MVP it's more likely that code you write is going to need to be totally revamped.
Acquiring tech debt in an early stage startup often results in never having to pay back that debt
Not true. In the case that your MVP is actually worth something, you don't want to be spending all your time paying off tech debt when you could be focusing on growth.
Quick honest question, what's your exposure and familiarity to finance?
But what if the product is a flop? Part of the benefit of "quick and dirty" is that you can quickly verify the market and iterate on product fit.
Would you rather have a well-designed flop, or a poorly-designed hit that you can't scale fast enough?
Remember Friendster from 2003? It's quite possible that it would have not lost to Tribe/Myspace/Facebook if it didn't take minutes to connect before eventually timing out.
There are things that are worse than wasted effort, and one of them is a hockey stick that slips right through your fingers. By the time the curve is inflecting, if you can't keep up, you're burning customers and inviting competition. If you have to rewrite at that point, you are going to lose to competitors with deeper pockets and no PR baggage.
Poorly-designed hit any day. Was this a trick question? :-)
(Obv, I'd prefer a well-designed hit, but I'd rather move fast and validate my market with a hack, than spend too much time and energy building something good that'll never be used.)
Poorly-designed market-hit is usually easier and more straightforward to fix than a well-designed market-flop.
I'll take the market hit any day! (Anyone remember the fairly pervasive "fail whales" along Twitter's bumpy evolution? Did they negatively impact the end state of the company?)
I do remember those, and iirc it almost sank the company. In fact I think that it absolutely impacted Twitter negatively, because the way they got through it was with massive investment in engineering funded by venture capital. So now Twitter is overcapitalized and beholden to be a size that makes that investment worthwhile, and can't make lean decisions that would be better for the world while also being sustainable for itself.
Let's ask ourselves, as either stakeholders or users of Twitter or participants in the culture borne of Twitter's poorly-designed success: are we happy with Twitter's arc?
I would rather have a Basecamp level of success that was well-designed and sustainable. And you don't get there by putting out a pile of shit and hoping for a runaway hit and then scrambling to raise billions so you can backfill everything you neglected to think about in the first place. The only ones who want that are VCs and the hyper-ambitious entrepreneurs who would rather have a billion dollars than make the world a better place.
Assuming you're building the correct thing. Small/early start up mode is about finding product market fit. The additional time is a waste that might never be needed or used. That additional time may also sink the endeavor. Regardless, no sense in beating yourself up and worrying about 20/20 hindsight. Software development produces two things of great value. Working software and information. Know what your current primary production goal is.