Don't Become A Tech Debt Horror Story
It’s October - the traditional time of year when all online content focuses on the most terrifying topics possible. The Rocketmakers blog, of course, is no exception!
Get ready to jump behind the sofa and cover your eyes as we bring you “The tale of the start-up that became a debt horror story!”
Scary as this story is, don’t give up hope! Rocketmakers has developed a series of tools and strategies, including our award-winning suite of microservices known as Orbit, which can bring tech debt down to a much less frightening level - more on this later!
Before we start our story, though, what exactly do we mean by tech debt? Put simply, tech debt is the cost (in time, budget or both) of additional work caused by choosing a quick-fix solution as opposed to a better approach. Deciding on this better approach may take longer at the outset, but will save headaches further down the line.
Act 1 - Our heroes bravely set forth!
Like all stories about tech start-ups, this one begins with a brilliant idea. It doesn’t matter what kind of idea it is. It could be fintech, a tech-for-good, or a way to build a better mousetrap. All that matters is that this idea is truly innovative, and revolves around a new digital product (an app or website or both).
However brilliant an idea it is, though, no one will know at first if that idea can sustain a new tech business. At this very early stage (which will focus on assembling a small team of dedicated diehards and raising investment), it’s important to keep investment in the technology itself to a minimum. This is for two reasons:
- There usually isn’t any extra money sitting around at this initial stage in the life of a start-up
- Feedback from potential users will probably inspire changes to the product, and there’s no point in doing too much work before that feedback is in.
To keep costs to a minimum, founders will often pitch to investors with a prototype of their app that is more of a simulation than the real thing. It will likely be a “clickable wireframe” or a “no/low code app” with just enough functionality to get the idea across.
This is absolutely fine as there aren’t going to be many users yet, if any at all.
Act 2 - In which our heroes stumble…
After that all-important early investment has been secured, it’s time for our intrepid founders to go to market with the first version of their app. This is usually called the Minimum Viable Product, or MVP, and (as the name suggests) this is meant to be a fairly basic version. The reasons for keeping things “minimal” are much the same as the reasons for using a simple prototype:
- The scope of the project will likely change as feedback comes in from users. Starting with a limited set of features makes it easier to respond to that feedback.
- Money is still scarce and needs to be spent wisely. Investing in features that turn out to offer little value to users is a mistake that is best avoided.
This second issue, the need to keep costs down during the early development of a digital product, can sometimes lead founders into making a decision they later regret. If they make the wrong choice, this leads to a TECH DEBT HORROR STORY!!!
We’ll explain how this happens in a moment, but for now let’s talk about what motivates the bad decision in the first place.
Developing a new digital product requires investment, and, as mentioned above, money is in short supply during the early stages of that development. It can be very tempting to take shortcuts during early development that can save both time and money.
For example, there are lots of easy-to-set up commercial products that will do important tasks for your digital product’s less glamorous functions. A great example is Google Firebase, which can almost instantly provide most of the back-end functions that most apps will need. Many of these services are also very inexpensive (even free) while there are only a handful of users.
With these shortcuts, it is possible to eliminate days, maybe weeks, of development time, and this translates into a huge cost savings as well. The initial running costs of a system built this way can also be very low - maybe just a few pounds a month.
Everything seems great, right?
Well…. Act 3 is going to start with more good news, but you’d best prepare for a pretty serious jump scare!
Act 3 - Initial success followed by TOTAL HORROR!
If all goes well, once an MVP is released into the wild it will become a runaway hit with users!
This is a moment for any founder to celebrate. Their new tech start-up is quickly heading towards scaleup territory and plenty of new investors will soon be asking if they can write a cheque.
However…. If the entire business model relies on a website or application that was built using the shortcuts mentioned in Act 2, things may be about to head towards Texas Chainsaw Massacre territory.
Here’s why:
- Quick and easy database solutions often lack the capacity to handle rapid increases in demand. This can mean that an MVP built on the cheap simply cannot handle a bigger user base, causing the app to crash or malfunction.
- When quick and easy databases are able to handle a rapid increase in demand, it often comes at a steep price. That low-cost or no-cost introductory deal could transition into a very high cost per user once you need to service thousands of accounts instead of a few dozen.
Unfortunately, this is just the start of the horror. Apps that rely on third party providers for basic functionality can be held hostage by that third party when it comes to price increases. If an app relies on Google Firebase and Google Firebase doubles its prices, switching to a new provider is often impossible without a substantial rebuild of the entire application.
And yes, that is an expensive proposition, and yes, this is why this phenomenon is called “tech debt”. In other words, cutting costs during early development can store up an enormous bill that has to be paid later on.
Tech debt can also result in losing more than just money. When a start-up’s application can’t handle a sudden increase in users, that creates a bad user experience. If an application has to be totally rebuilt from scratch to handle a larger user base, that transition will also likely inconvenience users.
This is the moment when the hockey-stick-style growth of a new tech start-up can come to a screeching halt. Maybe it’s become too expensive, even with new investment, to keep the app running at peak demand. Or maybe it’s become too expensive to grow any bigger, putting the transition to scale-up beyond reach.
Whatever the exact scenario, having to repay a substantial tech debt during a period of substantial growth is a genuine nightmare for any company on the verge of success.
How to reduce tech debt
Imagine rewinding our story back to Act 2, when the MVP was first being developed for the first paying customers. This was the moment, when any cost-savings during the development process was extremely tempting, the wrong choice caused things to go so wrong for our heroes.
At Rocketmakers, we live by the motto “build the right product and the product right.” This means that for any new development project, we try to build an application that users will love, and will have a robust-enough software architecture to scale as much as needed anytime.
In other words, while it’s impossible to eliminate tech debt altogether, we help our clients reduce it as much as possible while keeping costs as low as possible..
How do we do this? There’s not just one solution, but one method we are using increasingly often is an in-house product we’ve developed called Orbit.
Orbit is a series of pre-built software functions that appear in most digital products, like account creation, notifications, and data storage. Because it is pre-built, we can often get the most basic version of Orbit (known as Orbit Slingshot) up and running in a matter of hours. This makes it ideal for early versions of a digital product, like the MVP, where keeping costs low matters.
Unlike off-the-shelf 3rd party systems, however, Orbit is designed to grow without creating substantial tech debt. Orbit Slingshot can easily be converted to the full version of Orbit, and if there is a huge surge in account creation, or a huge demand for storing information, reconfiguring Orbit across multiple servers is straightforward.
Orbit can work with any Cloud provider, so our customers are never tied to just one database option. If Google Cloud raises their prices, migrating to AWS or Microsoft Azure is not a problem.
Best of all, Rocketmakers customers are free to “eject” Orbit any time they like. Because of its modular configuration, it’s possible to eject any Orbit section (we call them “capsules”) without impacting any other systems.
There’s no real reason to eject an Orbit capsule, however, as there is no charge for using them after an application is delivered, and there’s not even a charge for updates!
As mentioned above, using Orbit is only one solution for avoiding Tech Debt. Interested in hearing more?
Just get in touch and we’d be happy to talk you through all of the options.
Images by Miguel Teirlinck and Sergiu Baica on Unsplash
