Shipping a Flutter app and a Laravel panel from one spec

Most of our platform work ships as a pair: an administrative panel in Laravel and Filament, and a mobile client in Flutter. The failure mode is not technical. It is that the two teams quietly build slightly different products, and the difference only surfaces in acceptance testing.

Specify the contract before either side starts

We write the endpoint shape, the enum values and the translation keys once, before the first screen exists. Both teams generate from it. When a field changes, the change lands in one place and both sides notice immediately rather than at integration.

Keep the error states in the spec too

Happy paths agree by accident; error handling never does. What the panel calls a rejected submission, the app will call a validation failure, and the user will see two different explanations for the same event. Naming the states in the specification, including the ones nobody wants to design, removes an entire category of late rework.

Release cadences can differ, contracts cannot

A web panel deploys several times a week; a mobile release waits on review. That asymmetry is fine as long as the server never removes something an installed client still depends on. We version the contract and retire a field only after telemetry shows the last client using it is gone.