Startups need to prepare for success to have success

Entrepreneurs are always chasing the next milestone. For a while, it’s all about making your first dollar. Then your first million. If you’re lucky — and good — you grow the company to a point where you can consider an exit. Sometimes it’s an IPO. More often it’s an acquisition.

It’s exciting to have a large enterprise take interest in your company. But it’s also stressful to go under the microscope of a potential buyer.

The hood is up. Now you need to answer some fundamental questions, including the most important: Can your product scale?

You’ve always said it can – but can it really? Imagine getting dropped into a Cisco or a Microsoft or a Salesforce, with a massive sales force pushing your product. Bear in mind that scale has a way of revealing all your shortcuts and embarrassing hacks. How confident do you feel now?

It’s much better to get ahead of potential problems before they crop up. Acquiring companies tend to scrutinize some key aspects of your product, and this is where you should pay special attention so issues don’t crop up in M&A.

Double-down on data design

In a modern application, everything depends on data and the scalability of your transaction database. Elastic cloud infrastructure has made data architecture simpler, but it still needs to be one of your top priorities. A potential acquirer is going to want to see that if you’re serving 1,000 customers today you could jump to 10,000 or 100,000 customers in short order.

Even if you can quickly spin up new database servers in the cloud, you’ll run into trouble if they can’t communicate. It’s not as simple as running ten database servers instead of one. From an application design standpoint, you still need them all to work in harmony. It often takes additional effort to make data useful across servers. Deficiencies in this area usually won’t appear until you scale up, and at that point it’s too late. If you haven’t built in capacity from the beginning, it’s extremely hard to add later on in the process.

Don’t overlook the interface

Scalability isn’t just about the back end. I know of one startup whose early clients included a not-yet-ultra-popular ride-sharing service. At the time, most of the startup’s customers were keeping only 20 transactions open at once. The startup’s internal web application was designed to handle 50 — double the average load. What could go wrong?

The ride-sharing service caught on, and suddenly they had hundreds of thousands of open transactions in the queue. No one had thought to paginate the data returned from the server, so every time someone accessed this customer’s data, the whole system ground to a halt while the server built a massive HTML table.

The lesson I learned was to assume unreasonable success. You never know when demand is going to spike, so at every level of the application, you need to design for volume orders of magnitude higher than what you currently have — not just individual services, but the messaging between services. If you extrapolate from your current levels of traffic, you’ll never be ready for big opportunities. If you’re not ready to scale for organic growth, you won’t be ready for acquisition.

Respect resiliency

Closely related to scale — and just as important — is resiliency. Things are going to break. When they do, they need to come apart gracefully. When connectivity fails, when a bug gets into your code, does everything come crashing down or does your service just stop doing that one thing?

Have you gamed out what happens when different components fail? Can you automatically spin up new servers and dole out the work? Do the new servers pick up incomplete tasks?

What about your network? The single most dangerous aspect of your infrastructure, from a resiliency standpoint, might be the firewall. Some administrator tightens a firewall rule, and suddenly critical servers are cut off. You lose access to third payment processors, map services, all those external building blocks that modern applications depend on.

The best approach is to start with a totally locked-down firewall and then seek exceptions through a change-request process to open necessary ports. That way security has a record of why each port is open and has no reason to close them.

Lock it down

Every organization is vulnerable to cyber attacks, no matter how small. But once you embed into a Fortune 500 company, the threat level rises dramatically. Criminals will come at you however they can. Acquirers know this and want to see how well you’ve locked down your code and your security processes.

To cover the basics, you should run penetration tests at the application and network level. It’s often more effective to bring in security consultants from the outside. Not only do most startups lack security expertise, it’s hard for any organization to find their own blind spots. An outside perspective can spot vulnerabilities right out in the open.

While this may all sound like a lot to manage, it’s more than doable. You just have to do it before potential buyers come knocking. That means focusing on the less glamorous aspects of your architecture when it seems like everyone — customers, backers, even your own employees — are pressuring you to add features.  

No one wants to a buy a “fixer” if they can avoid it, but equally no one is expecting perfection. If you have the right mindset, and more importantly, act on it, you’ll be well ahead of your competitors, and in the best possible position to make the leap to the majors.