A regular topic of conversation in every post-pandemic board meeting these days has to do with buying or selling something. Often, the company itself is potentially on the block, but at other times the discussion is about acquiring a competitor ripe for a timely takeover, or an outfit in an adjacent line of business to add revenues and help cover fixed costs. No one wants to sit still right now, even though it's not clear whether the better, smarter, and safer path for the business is up or out. Everyone's got their own advice and suggestions on the subject.
This present angst may be the product of an emotional and physical hangover from the pandemic, where everyone's just really tired of fighting fires and struggling to stay alive. Or perhaps it's due to an unsettling sense that the big guys in tech have grown so immensely bigger in the last two or three years (most of them at least doubling their market caps in that time) and that they're even more dominant in practically every space that matters. Either way, there's just a ton of talk about trying to get bigger fast or cashing out entirely. Needless to say, discussing these two rather starkly opposed alternatives makes management, investors, and board members more than a little nervous.
All of these tense discussions revolve around a similar checklist, including accomplishments, valuations, risk factors, and market conditions. But the issue that has the most critical relevance for semi-mature startups (two to five years in the fight) isn't these considerations or the other obvious choices, such as sales, traction, and profitability. I'm referring to the much more difficult determination of "tech debt," which is an unavoidable part of the early stages of building any code-based business.
I call this problem "the pig in the python" which -- in its simplest terms -- means that there's often a pile of undocumented and sometimes entirely abandoned spaghetti code right smack in the middle of the business's core operating systems. This code helped to get you there, but now it's a cause of unnecessary friction in the system, it's creating serious documentation issues and raising personnel concerns -- in short, it's excess baggage that still needs to be maintained or eventually removed.
The prospect of having to clean up this very expensive code, which any young company has likely spent millions developing over the last several years, is one of the major deal killers that I've seen, even though it's an ordinary, expected, and completely typical part of the iterative process that every business undertakes. Buyers and somewhat naïve board members all want to know how you could possibly have spent so much on developing code that no longer plays a part in the current programs. Especially since someone new is now going to have to make it all go away (on their dime) they are likely to be unhappy or unwilling to bear both the costs of the remediation process and the competitive risks associated with it -- which may even be greater.
Hence, the classic wisdom around acquisitions: It's not how much you pay for the deal; it's how much the deal ultimately costs you. Tech debt is the embedded and hard-to-calculate expense of fixing and eliminating all the crappy code, false starts, ugly overhead, and other vagaries that still live in a business's code base many years after any of it ceased to have any value or effectiveness. Yet the business wouldn't exist without the trials and errors, unproductive directions, new product initiatives, and overall answers and ultimate improvements that the code represents.
Every software delivery system starts out big and bulky and ideally, over time, is streamlined, simplified, and sped up. The process is as unavoidable and inevitable as gravity. And anyone who thinks that it's an easy task to make a consumer-facing system look simple and be user-friendly has never built anything. As Richard Branson always says: "Any fool can make something complicated. It's hard to keep things simple."
Even more importantly, businesses need years to determine the best inputs and outputs to these systems, whether those are queries, searches, forms, reports, or responses. For startups, this simple reality presents a very serious risk. In tech businesses, you learn that anything really great seems obvious and inevitable in retrospect, but that's only to people on the outside -- never to the ones who had to suffer through the birthing process and make the millions of changes required to get to the end result. But being underappreciated for pulling off this trick and building this thing of beauty isn't the worst pain by a long shot.
Sadly, once you solve the riddle and create the ideal solution, everyone and their brother can jump right in and copy the front and back ends of your business and do it faster, cheaper, and even more efficiently because they aren't dragging three years of old code along with them. They haven't had to spend years and millions of dollars getting to the solution. They don't have a pig stuck in the middle of their process because they went to school on your solution, ran right up your back, and, most likely, even built their competitive offerings on better, faster, and more efficient third-party systems, clouds, and networks. This is not a happy story, but it is a familiar one. Not one startup in a million has invested in patents or other legal protection sufficient to help in this situation, nor they can afford the legal battles it would entail.
So, all of the remediation costs aside, in those buy-or-sell discussions, there's always the competitive risk element as well. How quickly will the competition be able to duplicate all the business's offerings for a far smaller investment? Worse yet, should the prospective buyer just take a step back and look into building their own version of the solution rather than buying yesterday's code and a bunch of other baggage? All because startups across the board are always in too much of a hurry moving forward to clean up after themselves and take out the trash. Documentation is also a pain and a burden, but it's another essential building block startups consistently neglect until it's too late.
A word to the wise: Invest the time now, before you think about trying to sell your business, to audit and purge your code base, confirm that your documentation is in order, and make sure that the loss of one or two critical employees at any point wouldn't put the entire operation at risk because of their unique knowledge and history. Take your own careful and detailed look at whether you should be cannibalizing your own code, moving some operations to someone else's cloud, and otherwise reducing your exposure and improving your own system's efficiencies by taking advantage of tomorrow's code rather than yesterday's.