3 signs your internal dev team needs support on the scale-up journey

Scaling up is one of the most important parts of your app journey. Your MVP is on the market, gaining traction and insights from real users, and now it’s time to start building out those bare bones towards the full vision for your product.

But scaling isn’t as simple as building more features and hiring more software developers. It’s about keeping the releases coming, creative problem-solving and making more efficient use of the talent you already have. Before you get started on your scale-up journey, there are a few warning signs to keep your eye out for.

‍

Read "Don't expect your app to take off from day one, building a digital product is a marathon not a sprint".

‍

Another week, another disagreement about how to structure the code base

‍

Architecture is one of the most important parts of software development. It’s intrinsic to an app developer’s craft, informing how they structure their code, source and render server data, and create the product people see and use on their phones.

It’s probably no surprise that developers have been arguing for decades about what the best app architecture is. There have been dozens over the years now and everyone has their own preference. But we’re not about to argue the case for our favourite – what matters most is that you pick one and make it clear.

If there’s no clear internal direction on which architecture you’re using, scaling will be chaos. Every new developer you bring on board will want to reinvent the system their way, and every feature or bug fix decision will start with an argument. New releases end up taking five times longer than they have to, and the development team starts to fracture.

Developers might not want to spend time learning a new architecture. But if half of your team is using Clean Architecture and the other half wants to refactor everything to Model-View-Controller because that’s what they’re more familiar with, it’s going to waste far more time in the long run.

You might want to adapt your architecture over time as your product and team evolves, and that's OK too. The important thing is that it happens by consensus and with intent, not by each developer trying to impose their own preference on everyone else. To move past these opinions and get your team aligned around a solid technical strategy, it might help to bring in an external expert.

‍

Following tutorials verbatim instead of learning the fundamentals

‍

As you scale up, your developers need to keep building their technical knowledge. Each new feature or bug fix has the potential to be something they’ve never faced before, and they need the right foundation of expertise and creativity to find the solutions. That’s why it’s important that when they’re honing their craft, they’re going beyond tutorials and using docs.

It’s about getting the right flow of information into your development team. Getting another software developer’s hands-on experience through tutorials might seem useful at first, but it can be a barrier to your scaling. For one, tutorial authors come from any background or level of expertise, and their context might not always fit with your own.

They’re inherently opinionated. Tutorials are one developer’s way of tackling one specific task, but their preferred method won’t be relevant to every situation your developers face. If they rely too much on tutorials, there’s always a risk they’ll invest their time following the author’s instructions only to find they don’t apply to the actual context at hand.

Docs are different. Rather than telling you what to do, they state what library or framework options are available and help you understand things at a fundamental level. That means developers can take in the information, form their own opinions, and apply that to whatever they’re facing next.

When you’re scaling up your product, it’s that fundamental knowledge you need most. Writing code isn’t like cooking – following one developer’s recipe step by step won’t give you the same result in your own app. Instead your team should work on understanding the ingredients so they can create their own recipes that are relevant to their work.

‍

‍

Holding on to manual tasks

‍

In the early days of building your Minimum Viable Product, your team will have had a lot of manual tasks on their plate. Smoke and mirrors is an essential part of the MVP process. Your focus is on building the crucial features and making your resources last through launch – automating everything behind the scenes just isn’t a priority.

Once you start scaling up you need more efficiency, and automating parts of the process like scheduling and review notifications is the answer. But after taking on those tasks for so long, developers often don’t want to give them up because it feels like their job and responsibilities are shrinking.

The problem is that your development team might feel busy because their schedule is always full, but all those manual tasks are a sledgehammer to productivity. Take releasing, for example. You might have a senior developer who’s also your release captain – they hold the keys for every new feature, update and bug fix, and nothing goes live until they press the big red button.

That’s great when you’re knuckling down for a few months to launch the very first iteration. But once your MVP is live you need to keep the releases coming regularly, and your release captain can’t be there for every single one. If they’re curled up at home with the flu, or sipping a piña colada on a Maldives beach, your release pipeline will clog up in no time.

If your developers fear automation, you need to start building a culture that embraces it as a positive for everyone. Automation isn’t just for working out the development snags that are winding up your project manager. It also means your developers aren’t spending all their time on admin chores, and instead can focus their time on building interesting features, pushing the envelope and using the skills they’ve spent years honing.

To learn more about scaling your product, check out our thoughts on safeguarding quality post-MVP. Or if you’re looking for support, don’t hesitate to get in touch.

‍