4 Real-Life Tips for Scaling Your Startup’s Tech Structures
Stuck fighting fires all day instead of delivering new features for your growing number of users? You're not alone.
I’d like to show you 4 real-life examples of startups struggling to scale their tech and how we overcame those issues.
Avoid their mistakes or find some inspiration for solutions. My hope is that after reading this, you’ll be able to pinpoint your own problem and start getting unstuck.
Escape the “Putting out Fires” trap
It’s easy to get yourself stuck in a “Putting out Fires” phase where everything you seem to do all day is just moving from one catastrophe to another without ever really progressing.
I’ve been in a similar situation.
A few years ago, we became responsible for developing and maintaining mobile SDKs. The problem was that the SDKs were quite buggy. Whenever an SDK crashed, it often took down the whole application into which it was integrated.
Keep in mind, at that time, those SDKs had several million active users. And that number was growing!
Even if you fix a bug in an SDK, it takes months for that update to reach all the apps and users that use the SDK.
We knew we had to do something, or it wouldn’t end well.
The solution we came up with back then was quite simple in principle. We built a safety net so that even if the SDK crashes, it won’t bring the app down with it.
It’s not ideal, but it fixed the immediate burning issue.
Another thing was building a battery of automated tests.
Usually, I’m not a fan of pursuing high test coverage as a sole number. Watching trends and covering critical scenarios makes much more sense. However, in this case, high test coverage numbers made lots of sense. It was much cheaper than facing many SDK bugs in thousands of apps in production.
That initial fix helped us escape the “Putting out fires” state and enter standard feature development.
Since then, those SDKs have grown 4 or 5 times in monthly active users.
The Dependency Hell
Technical debt haunted us in another one of our past projects, too.
The components were old, the dependencies were old, and the technology was old. It became clear that the longer we remained in that state, the worse it would get.
Worse, we couldn’t simply toss the whole thing out of the window. There was a significant user base already, and the solution was huge. By starting from scratch, we risked building it anew, but still wrong.
That huge user base needed new features, yet there we were, stuck with tech debt.
What a pickle.
Sometimes, there are no smart fixes to turn everything in your favor.
The best we could do was get our hands dirty and go dependency by dependency, component by component. We gradually upgraded the whole solution to the latest version.
The key to success was Panaxeans, who had experience with the older tech and the newer stack + some other technologies that’d come in handy. So, veteran full-stack engineers that could anticipate most issues before they even happened. We didn’t need dozens; two or three were enough. But their work was meticulous.
In the end, what was being postponed for years eventually got solved in a matter of months. We got unstuck, and the solution could move on to standard feature development and steady growth.
One Hero Developer Will Sink You
A single hero developer. Efficient or doomed to fail?
In small teams, i.e., when building an MVP, it’s useful to have one or two star developers who feel true responsibility and OWNERSHIP for your product. However, once you’ve found your product-market fit and need to grow, your team will grow too.
That’s when star developers become bottlenecks because no decision can be made without them.
We jumped on a project the other day that desperately needed to scale. The thing is, they weren’t able to because the startup’s CTO had all the information. That information wasn’t shared because he had his hands full and couldn’t react to every single request. Since there are only so many hours in a day, the project barely moved forward.
That’s not scalable and had to be fixed.
Before any development, we organized a few workshops for the client’s team.
We helped:
Bring some structure into their development.
Introduce automation.
Coached them in Scrum.
All of that brought more visibility and empowerment to the team. They started making informed and independent decisions without needing that one key person.
We achieved Team Ownership in that project, a key factor in scalable tech teams.
What You Can Do RIGHT NOW
Start making work items FOR the developers.
In smaller teams that need to iterate fast, it’s common to send a DM to a developer with what needs to be done.
I understand; it’s fast and simple but not at all scalable.
Once a team grows to a specific size, project management tools (Jira, Asana, Trello, etc.) become helpful – if the work items are written clearly and can be read and understood by anybody.
It ties into the Team Ownership mindset (my favorite) and empowers your team to make decisions, not depend on a single person with all the knowledge.
Minimize Context Switching
STOP what you’re doing RIGHT NOW.
Did you leave the stove on?!
That was a Context Switch, and I’m sorry. But if this happened to you dozens of times daily, your productivity would be effectively dead.
As a founder, you want to avoid switching the context for your developers as much as possible. Most of the coding they do doesn’t happen when they type on the keyboard. It happens in their heads when they solve problems.
So help them by leaving them peacefully in their state of flow. They’ll be happier for it, and productivity will soar.
Wrapping up
Found yourself in one of these real-life stories?
No worries if not. Tech scaling is a unique process that differs extremely case by case.
Feel free to send me an email with what’s stumping your tech growth at the moment. Perhaps we can find a solution together.
Also, I’ve explained some important tech growth concepts for growing your team and your codebase in other articles. You might find something useful there.
Good luck!
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.
