A 3-day diagnostic by a Senior Flutter Engineer. $500 flat. Ranked fix list bound to file and line, real-device frame timeline, 60-minute walkthrough with your team. Diagnosis, not implementation.
Audits shipped to Series A through Series C teams · NDA on request · 24-hour first reply
01 Symptoms
01
The first run after install has a frame storm. The home tab scrolls like it is underwater on mid-tier Android. A reviewer wrote “feels laggy” last month and you closed the tab. Your team noticed. You noticed. No one has said it out loud in standup.
02
State lives in three libraries because three engineers each had a favourite. A custom animation in home_screen.dart is untouchable. Tracing a bug is five directories and a Slack thread from 2024. Velocity has half of what it had a year ago.
03
They are good. They are senior. They still spend three weeks in the codebase before they ship anything, because no one wrote down which 200 lines actually decide the app. The thing inside the codebase that should be obvious is not.
02 Deliverables
The audit is one product. Not a retainer, not a sales call. You get five things and you keep them.
D01
Five to ten items, ordered by impact and effort, with the file and line where to start. Not a backlog. The audit ends with a sprint, not a wishlist.
OUTPUTMarkdown · 1–2 pages
D02
Before/after timings for your three worst screens, captured on real devices. The bottleneck is named.
OUTPUTHTML + screenshots
D03
Two pages your CFO can read. Risk, cost, fix. Send up the chain without translating.
OUTPUTPDF · 2 pages
D04
Engineers shipping the code in the room, real-time questions, recorded. The team leaves knowing what to do Monday morning.
OUTPUTRecorded call · 1 hr
D05
Notes, diagrams, naming conventions, and the three architectural decisions I would make next. The audit pays off long after I am out of your Slack.
OUTPUTMarkdown + diagrams
Preview: the 10-point Flutter performance checklist used for every audit. Read it below ↓
02b Read on the page · ten fronts
Ten fronts I open against every Flutter codebase. Your symptom binds to one of these — usually two. Tap any to see what the front is and how the audit closes it.
Users decide whether your app is good or broken in the first two seconds. Install funnels lose double-digit percentages when an app feels slow to open — the cost is paid before anyone sees a feature.
We measure exactly where the time goes between the icon tap and the first screen your team can call “ready,” on the mid-tier phones your real customers use. The result is a budget the engineering team can defend in every release.
Most of the savings sit outside the visible interface, in plumbing your team didn’t think to look at.
Most apps reveal themselves in three frames: the launch icon, a loading placeholder, and the real content. When those three don’t line up visually, users feel a flicker — and a flicker reads as “broken” even when the app is technically fast.
We measure and tune the transition on real devices so the open looks continuous on every screen class your customers carry. The first impression is the only one that’s free.
Image-heavy screens are the most common cause of crashes that never reach your dashboard, because the phone silently kills the app when memory runs out. The user sees a relaunch; you see nothing.
We trace where every photo is loaded, decoded, and held onto, and shrink the footprint so the same screens hold up on phones half your team would never test on.
The fix is rarely a new library. Usually it’s two settings nobody knew were defaults — and the user-visible result is the app feeling lighter on the devices your retention curve actually depends on.
There are two clocks running inside every frame, not one: the work to compose the screen, and the work to actually draw it. Most teams only watch the first.
When the second clock is the one over-budget, the dashboard looks healthy and the phone still feels stuttery — and users can’t articulate why, they just sense it.
We measure both clocks separately on real devices and tell you which one your team’s engineering hours should be aimed at. It’s almost never the one being measured today.
Every megabyte over thirty drops install conversion in the markets you most want to grow into. Users on prepaid data plans see the size on the store page and tap back — you never see them.
We open the app’s package byte by byte, name what’s inside, and rank the three changes that recover the most install share with the least engineering risk.
One of them is usually a single setting nobody noticed had reverted during a release. Smaller app, more installs, same product.
Reviews mentioning battery cost you more than reviews mentioning missing features — and they’re harder to recover from, because most users don’t leave a review, they just delete the app.
We measure where the app actually draws power on real devices, ranked and broken down by screen and feature, so engineering can target the largest line first.
Background work, location accuracy, and over-eager screen refresh are the usual three offenders. Battery is the quiet retention story behind almost every uninstall spike.
Some apps feel heavier the longer they’re used and quietly crash after twenty minutes. That pattern doesn’t show up in dashboards, doesn’t reproduce in QA, and is almost always a small piece of code that fails to release something it should.
We run scripted long-session scenarios, watch the memory curve, and identify exactly what’s accumulating — the same way a financial auditor traces a line item back to its source entry.
Long-session reliability is what separates an app that gets opened daily and one that gets deleted on Sunday.
The hardest bug to fix is the one that returns under a different stack trace. Most of those are timing-related — two parts of the app racing each other under load or on unusual user paths — and they need a different kind of investigation than a normal crash.
We follow those paths through detailed logs and reproduce the failure on demand, then prove the fix holds so it doesn’t reappear in a future release.
A bug that recurs is more expensive than a new one because trust compounds, both inside the team and with users.
Codebases drift the moment teams change. A library that was the right choice in 2023, a migration that started and stalled, a feature flag nobody flipped, a dependency frozen because everyone is afraid to update it — each one is a small tax, and your team is paying all of them at once.
We map every line of decay, weigh the cost in engineering hours, and hand back a sequenced plan to pay it down without freezing your roadmap.
Most teams overestimate the cost of fixing legacy code and underestimate the daily cost of not.
Most audits hand back a PDF of opinions. This audit hands back a sequence of tests — one per finding — that prove the issue exists, document the fix, and stay in your test suite forever as a permanent guard against the same bug returning.
Your team’s engineers can re-run every claim in the report. Nothing is taken on faith.
The audit is the deliverable. The tests are the receipt.
03 How I read code
A code review tells you what is syntactically wrong. An audit tells you what is structurally wrong. Which decision from 2023 is costing a week per release. Which animation is taxing every screen and nobody has time to fix. Which third of your codebase can be deleted without anyone noticing. Which migration started in 2024 and never finished.
The audit reads decisions, not code. I trace narrow, error-prone paths through detailed logs and real-device measurements until your symptom is bound to one named cause — not a list of guesses. Every claim in the deliverable is proved by a failing test before the fix, and a passing one after. Diagnosis is the hard part. The fix list is short on purpose. Most of the value is what is no longer there.
Parallel reading. While I do the manual pass, I run Claude in parallel on the same codebase — wide sweep across call graphs, dependency staleness, dead branches, state-management overlap, reproducer drafts. The agent does the breadth, I do the depth read, and both feed one diagnosis. The audit ships in three days because two engineers are working it — one human, one machine, neither replacing the other.
Proof, not opinion. Every issue is reproduced as a failing test before it is called a finding, and the fix turns that test green. Every change I propose lands inside the deep contract Flutter itself publishes for its framework — the documented behaviour every Flutter element is required to honour, verified against the framework’s own internal test suite. Nothing in the report is a hunch and nothing relies on undocumented behaviour. The tests stay in your suite afterwards as a permanent guard against the same issue returning two releases later.
Crash data welcome. If your team already collects Sentry, Crashlytics, Firebase, Datadog, or an in-house crash dashboard, share it. I trace each reported error back to the line of code that produced it, reproduce it on a real device, and measure how often it actually reaches users versus how loud it looks in the dashboard. The fix list lands ranked by user-pain, not by stack-trace volume — so engineering hours are spent on what hurts retention, not on what fills the alerts inbox.
04 How it runs
Tell me about your app and one symptom in your own words. A project link is optional — a description is fine. I reply within 24 hours either confirming we are a fit or telling you exactly why we are not. If we move forward, code access is sorted next, under NDA.
The repo end to end. State boundaries, navigation graph, render paths, isolate model, dependency staleness, ghost code, the three architectural decisions driving everything downstream. Churn × complexity hotspots ranked by close of day. Working notes you can use before the report lands.
Real-device measurement of every front: how each screen renders frame by frame, where memory is held and released, what the app does to the battery, how long the open takes, what each megabyte of size is paying for. Your symptom is bound to one named cause by close of day — not a list of suspects, not a backlog of guesses.
The ranked fix list (file and line, impact and effort), the perf report, the two-page stakeholder brief, the roadmap notes. Every finding linked to a reproducer test — red before the fix, green after, permanent regression guard. 60-minute walkthrough with your engineers, screen-share, real-time questions, recorded. Two weeks of async clarifications + PR review after.
05 Price
A 3-day diagnostic, not a full engagement. Senior day-rate elsewhere is $1,200–$2,400. This is intentionally lower friction — a real audit, scoped tight, designed as the first move.
Fixed at $500, paid on completion. Day 2 is a hard checkpoint: if the diagnosis has not bound your symptom to a named engine-level cause by then, you receive the partial trace and a full refund. Roughly half of audits surface a deeper engagement after — the $500 credits forward when they do.
06 Questions
Hiring takes three to four months and a salary. The audit takes three days and $500. The audit answers the harder question hiring does not — which senior, with which depth, against which file. If you still need to hire afterwards, the audit becomes the job description.
Eventually, yes — the audit is me reading your code. You do not need to share anything to book or to get a fit assessment. Once we agree to go ahead, code access is sorted under NDA. If sharing source ultimately is not possible, I will say so straight rather than push.
Yes. You are paying for diagnostic compression: three days of a senior engineer reading the codebase end to end, plus a ranked fix list, a real-device frame timeline, a stakeholder brief, and a walkthrough with your team. Senior contractor day rates run $1,200–$2,400. The audit prices under day-rate × 3 because the deliverable is bounded — diagnosis, not implementation. Same shape as a $5,000 audit, tighter scope. If the work runs over my budget, that is not your problem.
Often more so. Performance audits get the headlines; architectural audits change quarters. If your team is touching eight files for a one-field change, you do not have a performance problem, you have a coupling problem — same audit, different probe set: churn × complexity hotspots, dependency staleness, mutation score on the domain core, ghost-code archaeology, half-finished migrations.
Automated tools tell you what is syntactically wrong or statistically unusual. The audit tells you what is structurally wrong — which decision, which screen, which dependency, on which device. Tools see code. The audit sees decisions, and the cost of leaving them in place.
Day 2 is a hard checkpoint. If the diagnosis has not bound your symptom to a named engine-level cause by then, you get the partial trace and a full refund. The 3-day audit is sized to diagnose, not to rewrite. If your problem genuinely needs ten engineer-days, the Day-2 report says so with the scoped follow-on, and we both move forward with the right shape.
The audit is the product. Your engineers typically ship the fix list faster than I would — the audit names the file and the line, and the team learns the codebase along the way. For specialist work — custom rendering, large gesture rewrites, a complex migration off a legacy state library — I take implementation engagements after the audit, scoped per item.
Yes — legacy archaeology has its own probe set on Day 1. Half-migrated null safety, v1 Android embedding holdouts, Material 2 surfaces under a Material 3 root, abandoned isolates, several state-management libraries layered in one tree, dependencies frozen since 2023. The audit ends with a sequenced migration plan where every step is bound to a regression test so nothing silently breaks while the codebase moves.
07 The engineer
I am a Senior Flutter Engineer. The last several years have been spent reading, debugging, and unsticking Flutter apps in production — scrolling that drops frames on flagship phones, custom animations that have to look correct on a five-year-old Android, gesture work at 120 Hz, legacy codebases with three state-management libraries layered on top of each other that nobody on the current team wants to touch. I write custom rendering when the off-the-shelf path won’t hold the frame budget. I read frame-by-frame measurements when stuck — usually the fastest way out.
How I work: I trace narrow, error-prone paths through detailed logs and real-device measurements until your symptom is bound to one named cause — not a list of suspects. Every claim in the deliverable lands as a failing test first and a passing one after. The test stays in your suite as a permanent regression guard after I leave, so the same bug cannot quietly return in a future release.
What that means for you: when your app feels slow, heats the phone, leaks across long sessions, or just resists changes, I usually name the cause inside a day and bind it to a file and a line by end of Day 2. Legacy archaeology, half-finished migrations, abandoned isolates, the dependency that has been frozen since 2023 — same probe set, different findings. Diagnosis is the hard part. The fix is usually short.
I take one audit at a time. That is the whole business. No agency, no team, no handoffs, no junior doing the work. If you book the audit, you get me.
08 Book
Describe the one symptom in your own words. I read every form personally and reply within 24 hours with a fit assessment and a scoped quote.