A rewrite would expand risk
A wholesale replacement would duplicate authentication, navigation and platform behaviour while delaying product work.
Flutter Migration · at ANNA Money
Move one surface. Keep the product shipping.
A production add-to-app migration that embedded Flutter chat, accounting and tax experiences without replacing mature native accounting capabilities.
SpecialtyFlutter Migration
Formal role or capacityContractor · offer title: Android Developer
Personal scopeFlutter transition proposal, workshops, chat core, platform patterns, and native integration
SystemPigeon · FlutterEngineGroup · feature flags
01 · context
A migration problem, not a greenfield Flutter app.
The product needed to move selected surfaces without duplicating mature accounting capabilities or freezing delivery.
A controlled host boundary
Flutter needed to own selected features while Android remained authoritative for platform and accounting services.
02 · ownership
The contribution sits at the platform boundary.
Earlier experiments predated this work. The defensible scope is the later production integration and migration mechanism.
Production integration
- Interop and routing
- Engine and lifecycle handling
- Feature switching
- Flutter chat integration
Platform authority
- Authenticated requests
- Files and analytics
- Native-only actions
- Accounting and security capabilities
Selected experiences
- Chat and BDUI
- Accounting and tax
- Bookkeeping and invoicing
- Flutter-specific presentation
03 · system
Explicit APIs connect two independently owned runtimes.
The architecture preserves native guarantees while letting Flutter features evolve behind a stable host contract.
Route and lifecycle
Creates engines and screens, owns services, and remains the containing application.
→
Generated host contract
Requests, navigation, lifecycle and actions cross a typed interoperability layer.
→
Feature delivery
Owns selected UI and state, then calls the host at platform boundaries.
04 · decisions
Progressive by construction.
Each decision reduces migration coupling and preserves a rollback path.
Package Flutter as add-to-app
Use an embeddable production module instead of creating a separate replacement application.
Centralise engine lifecycle
Use FlutterEngineGroup and one host integration layer rather than letting screens create ad hoc engines.
Keep native services native
Delegate authentication, files, analytics and native actions instead of duplicating platform behaviour.
Roll out behind feature flags
Move one surface at a time and retain native fallback paths.
Allow evolutionary state models
Bloc and MobX coexist; chat uses an explicit intent/state/effect model.
05 · evidence
Public product surfaces, private-source architecture.
Public store visuals establish the accounting and tax domain; the technical narrative stays within NDA boundaries.
06 · outcome
A migration mechanism adopted beyond its core.
The team migrated chat to Flutter and launched a closed test. Other engineers then delivered additional Flutter features using the established platform patterns.
PRESERVED
Native ownership of accounting, security, routing and platform services.
ENABLED
Independent Flutter delivery for chat, accounting and tax experiences.
BOUNDARY
Android integration and host responsibilities are described without claiming unverified iOS implementation details.
Evidence & NDA boundaryThis case uses approved public visuals and a sanitised technical narrative. Private source, endpoints, credentials, configuration, customer data, and proprietary schemas are excluded.
Work together
Explore a role or project
Target role · Staff Mobile Engineer (Android + Flutter)
Worldwide remote · English / Russian
Novi Sad, Serbia · hybrid possible