> Once the product-market fit is achieved (...)
> it makes sense to start cleaning up the codebase.
This is very optimistic assumption that people will actually clean the codebase at some point. From what I've seen technical debt can stay very long time. Temporary hacks can become permanent.
Spikes/prototyping can be quite effective, but to be effective in writing spikes/prototypes a team must be disciplined to rewrite/refactor later. And from my experience teams are often not very disciplined and pile of spaghetti code begin to grow...
> The problem with this approach is that if the tech debt
> catches up with you faster than you can figure out the
> product-market fit. In this case it gets harder and harder
> to move and instead of going faster you go slower
Yeah. This is what I've seen. Even in startups quick and dirty code can be developed over months. And in such long time pile of spaghetti just piles up (people can make quite a mess in days. Imagine what they can do over months...).
> it makes sense to start cleaning up the codebase.
This is very optimistic assumption that people will actually clean the codebase at some point. From what I've seen technical debt can stay very long time. Temporary hacks can become permanent.
Spikes/prototyping can be quite effective, but to be effective in writing spikes/prototypes a team must be disciplined to rewrite/refactor later. And from my experience teams are often not very disciplined and pile of spaghetti code begin to grow...
> The problem with this approach is that if the tech debt
> catches up with you faster than you can figure out the
> product-market fit. In this case it gets harder and harder
> to move and instead of going faster you go slower
Yeah. This is what I've seen. Even in startups quick and dirty code can be developed over months. And in such long time pile of spaghetti just piles up (people can make quite a mess in days. Imagine what they can do over months...).