5 Tech Scaling Problems We Faced so You Don’t Have to
Your tech company is about to cross into that growth phase – your product has found its market fit, and you want to rapidly increase your number of users.
You’ve probably run into issues with scaling your tech structures that nobody else in the world has ever encountered.
Don’t worry, that’s normal. The old adage that everyone is unique is potent in tech scaling. Especially in its problems.
I’ve put together 5 archetypal problems we usually see in tech scaling. I’m quite sure you’ll find a familiar story among them, learn from the mistakes we had to solve, and hopefully get unstuck.
Read on!
#1 The Hero Developer
What is it?
A hero developer is someone who knows how your tech product or even company works. They are highly skilled and extremely capable as individual contributors.
In any company's early stages, this is usually the one person who gets things done. They are an extremely necessary lifesaver.
Why is it a scaling problem?
Once you want to scale your team, create new departments, etc, hero developers become bottlenecks.
All the knowledge and decision-making resting on one person's shoulders is a single point of failure.
How to fix it?
Adopt the Team Ownership Mindset. Turn the hero into a Team Lead. They will push others forward.
Yes, it’s a big step.
Yes, training others often takes a lot more time than letting one skilled person handle it.
However, in the long-term the Team Ownership Mindset brings it exponentially more value. A hero developer will never fill all the gaps, and if they try to do so, their team won’t grow.
Think of it as a crutch vs. a safety net.
If the hero developer is a crutch to the team, then the team cannot make a single step without one. With a safety net, the team is completely autonomous. If something goes wrong, the safety net ensures no real harm.
That’s what a Team Lead should be to your team – a safety net.
#2 Old Tech, Tons of New Users
What is it?
In one of our past projects, we were entrusted with a product with an already large user base.
The tech was fairly old and buggy, resulting in disgruntled customers.
Another aspect specific to this project was that this was a mobile app component used in hundreds of apps, meaning that any update took several months to reach the end users.
Why is it a scaling problem?
The number of users was growing rapidly. The product clearly did many things right because it became more popular daily.
You don’t need me to tell you that constant crashes, unhappy customers, and a rapidly growing user base are just a ticking bomb waiting to explode.
This state also prevents you from working on new features because you’re stuck in a constant loop of fighting fire after fire.
How to fix it?
Usually, an iterative approach works best. Not in this case.
When making mistakes is this expensive, you must find a viable way around it.
The solution we came up with back then was quite simple in principle. We built a safety net so that even when the component crashed, it didn’t bring the app down with it. It wasn’t ideal, but it fixed the immediate burning issue.
The takeaway is the eternal cliché that you should think out of the box.
Sometimes, the “usually best” approach will cost you dearly.
#3 Ditching the MVP
What is it?
Once the MVP has found its product-market fit, many companies believe that now that they know what they are doing, they should ditch the old codebase and build the thing again but better.
More scalable. Better organized. Cleaner code.
Why is it a scaling problem?
What often happens instead is that they do build it again but with the same issues.
Instead of one MVP, they now have two. Both are still MVPs. Keep in mind that the technology hasn’t been scaled at all.
How to fix it?
For 90% of our customers, the best course of action is to build on top of what they already have.
It’s likely the best course of action for you as well. Focus on what you have; don’t ditch your MVP code. Change the parts that prevent you from moving from one server to multiple servers. Break out some functionalities into separate services.
You know what I mean.
There are cases when it makes legitimate sense to rewrite the MVP, but those are few and far between.
You and your budget will most likely be better off with simply working with what you have and upgrading it step by step.
#4 Feature Avalanche
What is it?
The Feature Avalanche problem is later in a Scale-up’s life cycle. There has been some growth, perhaps even many happy and prosperous years.
Eventually, tech companies tend to reach a point where it’s hard to find new users without adding many new features.
Why is it a scaling problem?
New features without a clear vision might end up being a bit too niche, perhaps serving only a small percentage of your actual users.
It complicates the product, making it difficult to introduce even more useful features because there are already so many. Hence the name – a feature avalanche.
Every new feature is harder to implement and less valuable than the previous one.
That’s a very nasty place to find yourself in.
How to fix it?
Let me give you a billboard analogy.
You can keep sticking new posters on a billboard base. But if you do that for a long enough time, the entire structure becomes so heavy it topples over.
Therefore, when adding new layers, you have two options:
Remove some of the old stuff that has been turned obsolete by the new features.
Look into the foundational structure and ensure it can hold all the new stuff you’re sticking on top of it.
What we did in a similar project was to take a step back. We asked the product team to slow down the influx of new features. We looked at the foundations and tried to make them strong. Perhaps break things down a bit, reduce the complexity
However, the best thing you can do is be intentional about new features so you never end up in a Feature Avalanche like this.
#5 Dependency Hell
What is it?
As the scale-up lives in its happy years, which I’ve talked about before, they might get caught up in all the new updates they are rolling out and forget to keep their tech stack up to date.
In one of our past projects, the main tech stack was actually neglected for 5–6 years. The foundational technology went through 4 major versions in the meantime!
Why is it a scaling problem?
This ties into problem #4.
Most developers know that updating just one version is often tedious. Imagine the hair-tearing experience of being 4 versions behind. A tech stack this old cannot support new features. It’s only a question of time before something gives.
How to fix it?
That’s the million-dollar question.
The best you can do is not get into this situation at all.
However, if you do find yourself taking care of a project like this, there is no super smart “magic wand” solution.
You need to be familiar with both the old and new stacks, ideally with all the versions in between. Then, you must update the solution to the latest version, dependency by dependency, component by component. It might take months and need a few super senior hands to guide you through the process, but it’s the only rational way to scramble out of the Dependency Hell.
There is one more alternative: ignore my point 3, ditch everything you have, and start from scratch. How viable that sounds depends on your situation.
Wrapping up
If you wish to avoid all of these 5 traps that lay on the tech scaling way altogether, here’s a summary:
Adopt the Team Ownership Mindset and turn your hero developers into Dev Leads. That’s the best long-term investment any scale-up can make.
Sometimes, the generally optimal approach is not the best. Remember that your situation is unique, and what’s expensive for someone else might be optimal for you. Even if it means building safety nets around a crashing component.
There’s a 90% chance you shouldn’t ditch your MVP code, however tempting that might feel. Build on top of it; your budget will thank you.
Your tech is like a billboard. If you keep adding new features, make sure the base is strong enough.
Be proactive and avoid Dependency Hell at all costs. If you do fall into it, however, meticulous work, updating everything step-by-step, is the only way out.
I hope that helps!
If not, click the contact button, and let’s talk. Perhaps a 30-minute call is all you need to get unstuck.
Igor Liška — Co-Founder/Co-CEO
Let’s connect on LinkedIn →
I like building software just as much as I like building Legos.
Throughout the 14+ years of my engineering career, I’ve been a developer, an architect, a manager… Right now, I’m the Co-CEO of Panaxeo – the kind of company I’d always wanted to work for but couldn’t find any like it.
