This site was built in FlutterFlow and exported as a Flutter app. Taking ownership of the export meant making it build at all, and then making it something a person could maintain.
The constraint: The exported pubspec pinned about 45 dependencies at exact versions, roughly 25 of them transitive: platform interfaces and per-platform implementations that pub resolves on its own. Those pins were matched to the SDK of the export era, so pub get failed outright on collisions with the SDK's own pins for collection and intl, and on timeago capping intl. Clearing that got as far as dart2js, which then failed on three more packages.
The decision: Delete every transitive pin and list only what lib/ imports, letting the SDK win on the two it owns. Then take font_awesome_flutter to 11.0.0 and hand-edit the generated call sites, because every 10.x release subclasses IconData (now a final class), so no 10.x version can ever compile again.
What I rejected, and why: Re-exporting from FlutterFlow was the obvious move and is the one that doesn't work. A re-export regenerates the exact pins and restores the breakage, and the font_awesome_flutter fix required editing generated files by hand. The generator stopped being able to produce a build. Hand-maintaining lib/ is what was left.
What it cost:
Two SDK-pin collisions and three dart2js failures cleared.
About 25 transitive pins deleted; the pubspec now lists only what lib/ imports.
flutter analyze reported 0 errors the whole time dart2js was failing. Analysis passing isn't evidence the project compiles.
What I'd do differently: I would have written the import-boundary test first. Most of what came after was undoing structure the export had no way to express, and without a rule that fails the build, "we will keep it clean" is a promise rather than a property. The test arrived at the end, when it was catching things I had already fixed by hand.