A rescue is the engagement that starts from symptoms instead of a feature list. The app already exists, it is live, and something about it is failing: frames drop, sessions disconnect, crashes climb, releases take longer every cycle — or the team that built it has stopped answering. Rescue work is scoped against those symptoms, sequenced by severity, and delivered into a product that stays in production the whole time.

It is different work from building an app, and the evidence that matters is different. Anyone can promise a rebuild; a rescue is judged on whether the specific thing that is failing stops failing, measurably, without breaking what still works. That is why every rescue we run starts with an audit and a written plan — and why, when the plan says two weeks of fixes rather than a rewrite, we say so.

The calls we take

  • Performance — jank on scroll, animation stutter, slow startup, lists that choke on real data volumes
  • Stability — rising crash rates, dropped sessions, memory leaks that surface only after minutes of real use
  • Abandoned handoffs — the agency is gone, the repo is unclear, and nobody is sure where the signing keys are
  • AI-built codebases — a generated prototype that found real users and now needs to survive them; the AI code audit is the front door for these
  • Stuck roadmaps — an architecture where every feature ships slower than the last, which is a symptom as real as a crash

The Rescues Behind This Page

A live telehealth product, stabilised in production

YouMi is an online psychological counselling service whose Flutter app was live on both stores and failing at the thing it existed to do: sessions dropped, chat messages went undelivered, and the navigation stack leaked memory badly enough to crash between screens. In two weeks we rebuilt the layer with a real connection lifecycle — automatic reconnection, message queueing across network transitions — added full delivery-state tracking, and rewrote the navigation architecture on Flutter's modern routing APIs. The app never left the stores while it happened. In telehealth the connection is the product, which is why that engagement leads this page: a rescue is measured against what the product exists to do.

Performance proven at the unreasonable end

Fixing slow rendering requires having built fast rendering. Arcana holds a chat of thousands of streaming markdown messages at 60 fps; ExtraETF holds its frame rate under live streaming market data. Those ceilings matter for rescue work because they calibrate the diagnosis: when we profile your app, we know the difference between "Flutter cannot do this" — rarely true — and "this rebuild storm can be scoped away", which is usually the actual finding.

How a Rescue Runs

1. Audit

We review the codebase — architecture, state management, test coverage, dependency health — against the specific symptoms that prompted the call, and profile the app on real devices rather than trusting the simulator. You get a written findings report and a sequenced plan. Sometimes that plan is two weeks of fixes; sometimes it is a staged refactor; occasionally it is an honest recommendation to rebuild, with the reasoning attached.

2. Stabilise

The highest-severity symptoms are fixed first and shipped through staged rollouts, so relief reaches users in the first releases rather than at the end of the engagement. The app keeps its release cadence — freezing it would add an outage of the roadmap to the outage you already have.

3. Harden

Fixes get tests around them so the failure cannot quietly return, CI runs them on every change, and crash and performance monitoring is wired to catch regressions before reviews do. This is the difference between a rescue and a recurring appointment.

4. Hand over

The engagement ends with the codebase in a state a team can own — yours, or ours under team augmentation if you want the capacity to stay. The findings report, the plan, and the monitoring remain yours either way.

The Disciplines a Rescue Draws On

Frame-rate work

Performance problems get profiled before they get fixed — on mid-range hardware, under real data, with the timeline open. The usual findings are unscoped rebuilds cascading through the widget tree, lists rebuilding rows they should recycle, and work done during build that belongs elsewhere. Performance is a property of the engineering, not the framework: the same discipline that keeps a chat streaming at 60 fps is what removes the stutter from a product screen.

State-management refactors

Many failing apps are failing structurally: state scattered across screens, implicit dependencies, one change rippling into five regressions. We refactor incrementally — screen by screen, behind tests, while the app ships — rather than declaring a rewrite. The goal is an architecture where the next feature is cheaper than the last one was, which is the roadmap symptom reversing.

Real-time reliability

Dropped sessions and undelivered messages are lifecycle bugs: connections without a reconnection policy, messages without delivery states, sockets that die silently when the network changes. The fix is a real connection lifecycle, built once and owned — the discipline the YouMi engagement demonstrates and the reason it took two weeks rather than a quarter.

Memory and navigation

Leaks that crash an app after ten minutes of use hide in retained screens, listeners that outlive their widgets, and navigation stacks that never release what they push. We rewrite navigation on Flutter's modern routing APIs where the architecture demands it — YouMi's did — and we verify the fix with memory profiles, not optimism.

Abandoned-agency handoffs

A takeover starts with archaeology: repository access, signing keys, store accounts, backend contracts nobody wrote down. We have run this recovery before and know its traps — keys that exist only on a former contractor's laptop, store listings owned by the wrong account — and the audit's first deliverable in these cases is simply an inventory of what you actually control. It is unglamorous work that has to be done before any engineering matters.

When it really is a rewrite

Some apps arrive beyond economic repair — an architecture fighting the framework, dependencies years stale, no tests to refactor against. When the audit says that, we say it, with the reasoning in writing, and the conversation becomes a scoped rebuild informed by everything the audit found. What we will not do is bill a rescue against a codebase we already know is a teardown.

What a Rescue Costs

The audit is a fixed-scope engagement: $5–15K, the same full-audit tier published on the AI code audit page — the machinery is identical whether the code was written by an agency, an in-house team, or a model. Stabilisation work is then scoped from the audit's sequenced plan, symptom by symptom, so you approve work in slices rather than committing blind. If you want the capacity to stay on afterwards, the published team augmentation rate applies: $10–14K per senior engineer per month.

We do not quote stabilisation prices before the audit — a number produced without seeing the codebase would be a guess wearing a suit, and most teams that arrive at a rescue have been burned by exactly that kind of quote once already.

Frequently Asked Questions

Common questions from teams whose Flutter app is failing in production.

Yes — some of our best-documented work started exactly that way, including a live telehealth product we stabilised while it stayed in production. A takeover begins with an audit of the codebase and an inventory of what you actually control: repository access, signing keys, store accounts, backend documentation. You get a written findings report and a sequenced plan before any rebuild conversation happens, because sometimes the answer is two weeks of fixes rather than a rewrite — and when it is, we say so.
By profiling before changing anything — on mid-range hardware, under real data volumes, with the performance timeline open. The common causes are unscoped widget rebuilds cascading through the tree, lists rebuilding rows they should recycle, and heavy work running during build. Flutter itself is rarely the ceiling: the framework holds 60 frames per second through streaming, animation-dense screens when the rendering is disciplined, so the fix is almost always scoping the work correctly rather than fighting the framework.
Usually not, and the audit is what answers it honestly. Most failing apps have specific, fixable causes — a missing connection lifecycle, scattered state, leaking navigation — that a sequenced refactor addresses while the app keeps shipping. Occasionally a codebase genuinely is beyond economic repair, and then the audit says so in writing, with reasoning, and the conversation becomes a scoped rebuild. What you should not accept from anyone is a rewrite recommendation made before reading the code.
Repository access, a build that runs, and whatever exists of store accounts, signing keys, and backend documentation — plus the symptoms as you experience them, in plain language. Missing pieces are normal in rescue situations; part of the audit in handoff cases is establishing what you actually control and recovering what you can. A current production build and access to crash reporting, if you have it, shorten the diagnosis considerably.
Yes — that is a design constraint of the engagement, not a hope. Fixes ship through staged rollouts in severity order, so users feel relief in the first releases, and the app keeps its normal release cadence throughout. We stabilised a live telehealth product this way without it leaving the stores. A rescue that requires taking the product offline is a rebuild wearing the wrong name, and we would tell you that at the audit stage.
Yes, and it is an increasingly common call: a generated prototype finds real users and then meets production, where security holes, runaway API costs, and architectural shortcuts surface quickly. Our AI code audit exists precisely for this codebase profile and runs the same way as any rescue audit — findings report, severity-sequenced plan, then fixes. Generated code is not unfixable; it just fails in patterns we have learned to look for first.

Read the YouMi case study for the rescue this page is built on, the AI code audit page for the audit machinery, or start from the Flutter app development pillar.