Victor Munoz of Moonshot Consultants – Things To Enable Your Start-up to Scale

The top 5 (technical) things you need to know that will enable your start-up to scale 

A lot of interesting technology has come out of startups, in one way or another. The environment they foster no doubt is part of the reason. Fast innovation, not encumbered by heavy bureaucracies and countless levels of management, can certainly yield impressive results.

It is also true that the very same characteristics that empower the creation of innovative solutions can also foster systems so loose the end-result is less than impressive. These solutions tend to resemble a Neogothic hospital built deep in the middle of a dark forest: it has some interesting bits, and it can be exciting to look at, but in general it is just terrifying.

How can we know whether our shiny startup technology is going to turn out a stroke of genius or a doomed problem child? In my travels I have found some key characteristics that can help us not predict the future, but certainly guide our decisions far away from the problem children of the startup pantheon.

One: Today’s shortcuts are just tomorrow’s headaches (or: Technical debt is just like regular debt).

Let’s be honest, technical debt is inevitable. There’s always that unavoidable deadline, that vital feature. That is absolutely fine, believe it or not. Creating technical debt is just a side effect of plans making contact with reality. The problem appears when technical debt is allowed to stay indefinitely.

Imagine you take out a loan. You need to pay back, but there is also the not insignificant issue of interests. Of course, the longer you take to pay back, the more interests you will accrue. They are the self-regulating enforcement mechanism to avoid generalised payment delays.

What is the difference between financial debt and technical debt? None. Both should be paid in a timely fashion, lest you want to pay a heftier price than anticipated. Technical debt will accumulate and solidify, making it more costly not only to remove it, but to add new functionality around it.

Always pay your debts back on time.

Two: Build fast but build steady (or: Choose technology that will stand the test of time).

Move fast and break things. Got it. But, like all things, this only makes sense in moderation.

At the beginning of any startup-shaped venture everybody is excited, and we all want to build our MVP and put it in front of potential customers. That is all fine, but rushing might coerce us into choosing a technology we are already familiar with, or a framework that promises a quick first iteration.

Successive product iterations will supply us with much more information about the required characteristics. A frequent problem presents itself at this point: the technological choices made for the MVP have solidified, and cannot be reverted without significant changes, if not a complete rewrite.

Although we are not in the business of fortune telling, it is important to have at least a superficial understanding of the architectural characteristics our product will need to support. With that data in hand, it will be much easier to choose technology that will not stand in our way come time to scale up.

All choices introduce limitations, but some will limit you more than others. Never code yourself into a corner.

Three: Code runs on infrastructure (or: DevOps is vital from day zero).

Writing code and playing with database engines can be really fun. Of course, getting software in front of customers does require infrastructure for them to run on. Maintaining this infrastructure can be a lot less fun.

Although many platforms promise high scalability without worrying too much about the details, their cost structure scales far worse. At the point in which a medium-sized project starts getting serious traffic a more tightly controlled solution becomes almost a necessity.

Some people think DevOps is just an angry guy you hire to keep your systems running. It can be but, ideally, DevOps is an organization-wide philosophy, aimed at eliminating silos and reducing friction from development to deployment. If an organization implements this philosophy from the beginning, instead it being bolted-on as an afterthought, the resulting infrastructure will be much more fit for purpose. This will not only result in faster iteration cycles, but also will help keep costs tight, and downtime and service disruptions to a minimum.

A little bit of work at the beginning will save you a lot of pain down the road.

Four: Persistent data should persist (or: Bad database choices will eat your data).

In this day and age there is a veritable cornucopia of database technologies to choose from. Some of them even make incredible claims about their capabilities. Of course, there is no such thing as a free lunch.

Data is at the core of most, if not all, software companies. Some of those pieces of data will turn out to be pivotal in the fate of the product. Such information tends to require proper persistence properties, as losing it would be utterly catastrophic.

Although choosing a novelty database engine can be tempting, it is important to use only time-tested and reliable systems for business-critical information. The way certain systems behave everything seems to be fine for a long while; but, once the system starts receiving pressure from an increased customer load, disaster strikes. Avoid disasters, use boring databases.

Also, design and verify a backup strategy. Really. Critical problems are a certainty over a long enough timeline.

If you care about a piece of data, make sure it is safe.

Five: Silos kill progress (or: Collaboration and communication are a key asset).

Any kind of software company is fundamentally like a stool: it requires at least three legs to stand upright. Those three legs are engineering, customer acquisition, and customer success. The last two inform engineering decisions, allowing technical teams to make decisions based on real customer needs and competitive pressure. The same goes the other way: if there is a technical requirement affecting the roadmap, it is better to communicate well and early, so we can put in place measures to manage expectations.

Now, imagine establishing those healthy feedback loops if nobody is talking to anybody else. Engineers will build features nobody wants, customers will be frustrated, and competitors will eat our lunch. Not exactly the pinnacle of industrial success.

We are all in the same boat, and we all want our brainchild to do well in life. Why not just talk to each other, then? I have often witnessed the most convoluted solutions to problems which would not have survived a five-minute conversation.

Technology is great, but words can solve many problems too.

The golden rules(s).

If I gained the ability to travel through time and space, what would I tell my former self? First, 2020 is going to be a crazy one, and 2021 will not be much better. But also, if I only had time to tell that strapping young fellow two things, I would say: take time to get your technology choices right, and talk to people. People are behind a great deal of technology failures, and their problems can only really be solved through open and honest communication.

Victor is Co-Founder at Moonshot Consultants, to learn how Moonshot can super charge your start-up contact [email protected]