Don't Sell Until You Clean Up the Code
A lot of software-dependent startups, having survived the pandemic intact, are now at the "move up or out" crossroads. But there's a hidden risk buried deep in their digital architecture.
BY HOWARD TULLMAN, GENERAL MANAGING PARTNER, G2T3V AND CHICAGO HIGH TECH INVESTORS@TULLMAN
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 (2-to-5 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, 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 (on their dime) is now going to have to make it
all go away and is 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."
And, 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 or 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 and, even
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.
JUL 20, 2021