Can you save a problem app as a small team?

We received a similar question to this in one of our recent webinars, and it’s not the easiest to answer!

Of course, as a mobile app development agency, our instinct is to say: ‘Let us work on it, we’ll sort you out’ - but that’s not always the right first move, and we wouldn’t be us if we weren’t 100% honest about that.

The truth is, you need clarity before you can do anything - whether your team is big or small. A “problem app” usually gets labelled as a technical issue. Legacy code, fragile infrastructure, missing documentation… sometimes all of these things are at play, sometimes it’s just one issue.

But, you can’t act on uncertainty. That’s a recipe for sunk costs and even bigger problems. If no one is quite sure how risky your app’s issues are, you can’t take any confident steps forward.

With a smaller team, that uncertainty is expensive. The greater hesitation and more frequent context switching we see within teams working lean is far more damaging than imperfect code.

In these scenarios, that clarity becomes all the more important. When the stakes are higher and the amount of hands on deck to repair is lesser, your remedial actions need to be targeted.

Structured, exact, trustworthy. It can be hard to know where to start with this, but here’s how we’d do it…

We always start with an audit. Sure, this is a service we offer to our clients before we take on any app, but you’re able to get some of that clarity yourself too (this isn’t a sales push!).

An audit isn’t some meaningless exercise designed to point fingers or produce a long list of problems. For teams with limited capacity, it’s value is in creating a shared baseline with actionable next steps.

A good audit should segment your app into the following areas, making that first look more manageable. This is where we like to start:

• Your codebase and database - have a look at your technical areas. Any security risks?
• Your environment - how is your testing coverage? What are your build targets? What are your IDE capabilities?

After that, you’ll want to start building a roadmap to improvement. Don’t jump in and start fixing right away! With a small team, this is a recipe for overwhelm and mistakes. Here’s what we’d do:

• Form the backlog - based on your audits, create a backlog of the critical work needed to save your app (prioritise the danger areas first, think app store policy violations and insecure API’s).
• Create guardrails for improvements - before actioning your next steps, set up guardrails around your release protocols, monitoring and continuous QA (this will help your teams maintain clarity across their work, rather than having to seek it out).

This is exactly how we structure our app audit service, so we’ve seen it work first hand. Truthfully, this process is important for any team size, big or small, but we feel it’s especially important for a smaller team to have a process like this.

Working lean can mean jumping around, shifting roles and just generally being more collaborative than organisations with more resources may have to. When this happens, structures can break down and mistakes are more common - meaning your app can end up at a greater risk than when you started.

With an audit structure, your small team can be guided through the process of recovering and managing a problem app.

The result? A clear route to rescue, broken into manageable chunks, with an app that remains in users hands - where it belongs!

We don’t like plugging our services in these blogs, as our goal here is to support app owners with simple insights and shared advice.

That being said, we do have a free diagnostic tool (entirely free, no code required) that can help you form the type of technical action plan that we would offer in a full app audit, which you can use here.