I don't have a story on startup failing due to tech debt, but I do have a story about technical debt forcing us to pass on potentially acquiring a startup.
A potential acquisition came our way that seemed to be exactly what we were looking for. Customer traction and revenues, the features exactly what we were looking to overhaul. There was very high internal interest in acquiring the technology and the company.
The need for this set of features was so high and the internal development estimated to be so costly (in developer time and delays in other projects) we were willing to overlook that this app was not built on our primary stack and only a few of our developers were familiar with. The language choice made by the company didn’t cool our appetite. However, technological choices made us pass on the acquisition.
They didn’t use a framework.
This means that our developers would have a very long learning curve. We also saw a lot of code that did what a framework would have taken care off and this means that we would have had to learn, maintain and expand the that code instead of working on the revenue generating features.
We found close coupling of code all over the place. This meant we couldn’t quickly extend and modify the features as we wanted without first paying back the technical debt accumulated by the developers.
It wouldn’t have mattered which framework they would have chosen as most of them have good documentation and force some sort of standard development practices. However, we couldn’t take a chance that all the behind the scenes stuff would need a rewrite if we wanted to expand and scale the platform. We passed.
Heh. I once joined an early stage startup that had a big bowl of spaghetti code, no source control and no framework. My first insistence was source control. Then after a year in which we hired several developers, I insisted we move to a framework so the learning curve wouldn't be so steep for new people.
It was a monumental effort that took more than a year to complete, and we did the "brain transplant" (as we called it) at the same time we were moving to a new data center. Launch was shaky but overall it went very well. One of my fondest memories is of the "war room" on launch day as we triaged incoming bug reports. The team worked great together and at the end of the day we felt like we'd really accomplish something.
Yeah, that reminds me of one of my roles in a company when we were deciding if we wanted to ally with another one. I'd be tasked with spending some time looking at their code base and talking to their technical people to decide if the alliance was technically worth it. Can't remember any of the judgments I made (was a quarter century ago), but my input was an essential part of the decision.
Folks rarely notice how much a decision making matters on this regard and technical knowledge matters a lot on the way. Since having a company* acquired sometimes could be a good business return, but in the first place due to hitting the pedal it has brought lots of technical debt which makes an acquisition impossible.
A potential acquisition came our way that seemed to be exactly what we were looking for. Customer traction and revenues, the features exactly what we were looking to overhaul. There was very high internal interest in acquiring the technology and the company.
The need for this set of features was so high and the internal development estimated to be so costly (in developer time and delays in other projects) we were willing to overlook that this app was not built on our primary stack and only a few of our developers were familiar with. The language choice made by the company didn’t cool our appetite. However, technological choices made us pass on the acquisition.
They didn’t use a framework.
This means that our developers would have a very long learning curve. We also saw a lot of code that did what a framework would have taken care off and this means that we would have had to learn, maintain and expand the that code instead of working on the revenue generating features.
We found close coupling of code all over the place. This meant we couldn’t quickly extend and modify the features as we wanted without first paying back the technical debt accumulated by the developers.
It wouldn’t have mattered which framework they would have chosen as most of them have good documentation and force some sort of standard development practices. However, we couldn’t take a chance that all the behind the scenes stuff would need a rewrite if we wanted to expand and scale the platform. We passed.