The founder had been paying a developer for months. Then the developer stopped replying to messages.
What he handed me was a Flutter project with no README, no comments, and more than one state management library fighting over the same data.
He wanted to know one thing. Should he throw it away and start again?
Almost always, no. There's real work buried in there, and more importantly, there's business logic and edge cases he asked for months ago and has since forgotten about. Start from scratch, and you rediscover all of it the slow way, usually after users hit it.
So before touching any code, this is the order I work in.
1. Get it building
Nothing else. Wrong SDK version, packages that no longer exist, signing keys nobody kept, a Gradle file untouched for a year. Going from a red build to a green one teaches you more about a project than reading the code does.
2. Use the app like a normal user
Write down every screen that loads and every flow that actually finishes. Founders usually have no idea how much is genuinely done versus half wired up. This list is often the first honest status report they've had in a long time, and it's the thing that calms everyone down.
3. Follow the data
Not the code, the data. Where does it come in, where does it get stored, where does it get displayed? Most abandoned projects fall apart here rather than in the UI. If two libraries are both trying to own the same state, you've found your real problem.
4. Stop the bleeding
Crashes and data loss first. Not architecture, not clean code, not a rewrite. Just get it to a state where it isn't actively breaking.
Only after all of that is it worth deciding what to rewrite. By then you're making that call with information instead of frustration.
If you've got a Flutter project sitting half finished right now, it's probably in better shape than you think. Send it our way and we'll tell you honestly whether it's worth saving.
