Cross-platform, one year later

We do not usually get to check our own homework this cleanly, but a fintech client we shipped a Flutter app for in early 2025 asked us back a year later for a maintenance retrospective. What follows is what the decision actually cost and saved, measured against the estimate we gave them before the build — not the estimate we would like to have been right about.

What we told them going in

Before the build, we estimated Flutter would save roughly 35% of engineering time versus two native codebases, with the main risk being biometric authentication and a card-scanning SDK that we had not yet confirmed had solid Flutter support. We flagged both as spike risks and scoped two days to de-risk each before committing.

What actually happened

The time saving landed close to predicted — we measured 31% fewer engineering hours over the twelve months, most of it in the categories we expected: shared business logic, shared form validation, and not maintaining two versions of the same onboarding flow. The card-scanning spike found a gap in the plugin ecosystem exactly as feared, and we wrote a thin native platform channel to a well-maintained native SDK on each platform — two days of scoped native work, exactly as budgeted, not a project-wide fallback to native.

Estimated:  ~35% fewer eng hours vs. two native codebases
Measured:   31% fewer eng hours over 12 months
Native fallback needed: 1 feature (card scanning), 2 days as planned

The thing we did not predict

What we underestimated was app size and cold-start time on the client's lowest-end supported Android devices, which matter more in the markets this app actually shipped into than they do on the test devices we build on. Two release cycles went into tree-shaking unused packages and lazy-loading a heavy chart library that was only needed on one screen — work a leaner native build would not have needed, though it would have paid a similar cost somewhere else.

Would we choose it again

Yes, for this client and this app shape — mostly forms, balances, and transaction history, with one camera-heavy feature we correctly identified as the risk up front. The lesson we are carrying into the next fintech build is not about the framework; it is that the spike-the-risky-feature-first approach worked exactly as intended, and we now run it as a standard first sprint rather than an optional step.