Rocketmakers Logo
Rocketmakers Logo

Share this blog post

The Growing Pains of Software Development

By Ned Vaught
10th Mar 2023
4 min read

As digital products scale, they inevitably experience “growing pains.” 

These aren’t necessarily a problem - they are caused by growth after all - but it is a critical moment in the lifecycle of any application. 

If these challenges are addressed well, a product will be set up for years of continued growth. If they aren’t handled well or ignored, you can be sure it will lead to even bigger problems before long.

Here are three growing pains anyone managing a scaling digital product should look out for, and how Rocketmakers advises addressing them to avoid any slowdowns in growth.

#1 - Tech Debt

The first version of a new digital product, often called a minimum viable product or MVP, should be made as quickly as possible. This gets it into the hands of users, and provides an opportunity to make changes based on feedback.

Because the initial version is unlikely to have a large user base, at least initially, a good developer will identify opportunities to take shortcuts and implement time-saving but suboptimal solutions that will work on a small scale. This is a smart play - it’s not worth spending the time or money to get a project just right until you know it’s going to be successful. 

If the MVP is successful, and the user base starts to grow, it’s time to start addressing that build up of shortcuts and suboptimal solutions. The longer this is put off, the harder it will become to maintain and update the application.

This phenomenon is known as “Tech Debt” and, like other forms of debt, not paying it will eventually create problems. 

A classic example of this is payments. For a small user base, it may make sense to process payments manually rather than invest in a fully automated system. As the user base scales, a manual payment process could become a brake on growth. 

It’s important to understand that Tech Debt is a good thing if managed properly. An MVP that has no tech debt is probably too large, so it can be viewed as a way to de-risk early development projects. Tech Debt only becomes a problem when it is ignored or postponed too long.

SOLUTION: Take decisions that create Tech Debt strategically, and document what will need to be done in future and when it will need to happen. This is standard procedure for all Rocketmakers projects, and an important way to avoid expensive rebuilds in future. Just as you will for other types of debt, plan when and how Tech Debt will be repaid. 

#2 - Software architecture and infrastructure

After launch, an MVP may only have a few hundred users, or maybe even fewer. At this stage, it doesn’t normally make sense to invest in robust software architecture and infrastructure that can accommodate millions of users. Budgets for early version development should be kept low, so a cheaper and faster solution that meets the needs of a smaller user base is usually the best option.

Where things can go wrong is if the solution used for a small number of users is very difficult or impossible to reconfigure to accommodate substantial growth. 

For example, some cloud-based server options might be free for a small database, but then charge significantly higher fees if the database expands and the number of server calls grows significantly. Depending on the product, these fees might be unsustainable, and the database might have to be migrated to a new cloud provider. This is always possible, but will likely create a disruptive user experience - not ideal if you are right in the middle of a sudden spike in user numbers! 

Keeping costs down during the MVP stage is important, but it should never be done in a way which will hinder growth.

SOLUTION: Building an MVP with software architecture designed to scale doesn’t need to be more expensive. At Rocketmakers we use a system called “Orbit” which deploys scalable “containers” on cloud-based servers. Using Orbit, we can create an MVP that runs using just one container, but can quickly spin up new containers to meet surges in growth. Because Orbit is designed with scaling in mind, the process is straightforward and fast.

We’re also experts at selecting cloud hosting options that fit the budget of any MVP, but can expand to meet demand without any costly surprises. 

#3 - Vendor tie-in

Most digital products contain dependent technology which can accelerate the development process, improve the user experience, or both.

For example, for the complicated process of account creation and management, many apps are built using third-party applications such as Auth0. For notification templates, it is quite common to use a third-party provider like SendGrid to store and manage them. Both Auth0 and SendGrid allow small applications to use their software for free - a price that is difficult to turn down when you’re on a budget.

Where this can go wrong is if a digital product is built so that it will only work with that third party’s software (or hardware, depending on the example). This can make it very difficult or very expensive to switch to a competing vendor’s product - something known as “vendor tie-in.”

Because many services start free but have a tiered pricing model with significant jumps in cost between tiers, problems with vendor tie-in can arise pretty quickly once an application’s user base begins to grow. This means a sudden spike in users can easily trigger charges from dependent service providers that amount to tens or even hundreds of thousands of pounds. 

Understanding exactly how dependent an application is on these providers is essential, and putting steps in place that sidestep any nasty surprise is something that should start from Day 1 of the MVP build.

SOLUTION: At Rocketmakers, we use Orbit to provide the most commonly occurring features in all applications, including account and template management. There’s no extra charge for using Orbit, and no ongoing cost other than the server computer needed to run it. There’s also minimal vendor-tie with Orbit, as each component is designed to be straightforward to update and painless to repair or “eject.”

Are you starting an MVP?

If you’re starting an MVP, it’s important to look ahead to the scale-up stage and make sure you’re prepared to handle the inevitable growing pains. If you’re experiencing growing pains now, and want some help from experts who know the easiest and fastest way to solve them, we’d love to hear from you. Just get in touch and let us know how we can help!

Image credit to Markus Spiske from Unsplash