The conversation usually arrives the same way. Field staff, or drivers, or site supervisors are using the web application on a phone browser and hating it. Someone asks what a proper mobile app would cost. The number that comes back assumes rebuilding the platform, and the project quietly dies.
It does not have to go that way. Your existing system already contains the projects, the tasks, the documents, the permissions and the workflow rules. None of that needs to be rebuilt. It needs to be reachable.
The app is not a smaller version of the website
The most common mistake is scoping the mobile app as "the web application, on a phone". It never is, and trying makes the project far bigger than it needs to be.
A site supervisor standing in the rain does not need your reporting module, your admin screens, or your invoice designer. They need to see today's jobs, open one, mark a task complete, take a photo, and leave a note. That is four or five screens.
Scoping to what the field role actually does is the single biggest cost lever available, and it usually takes the project from "unaffordable" to "obvious".
The work is mostly on the server
Counter-intuitively, most of the effort in a mobile project like this sits behind the API, not in the app.
You need endpoints shaped for the app's screens rather than your tables — the previous article covers why that distinction matters. You need authentication that suits a device rather than a browser session. You need to decide what happens when a phone has been offline for six hours.
Once that exists, the Flutter or .NET MAUI work is comparatively contained. The app is a client.
Three problems that are specific to field work
Connectivity is not a given. Basements, rural sites, steel-framed buildings. If the app assumes a connection, it will fail exactly when it is needed. You do not necessarily need full offline sync — that is expensive and genuinely hard to get right. Often the correct answer is more modest: cache today's jobs on open, queue writes locally, retry when signal returns, and be honest in the UI about what has and has not been sent.
Photos are heavier than everyone expects. A phone camera produces very large files, and field staff take a lot of them. Resize on the device before upload, upload in the background rather than blocking the workflow, and decide early where those files live — because doubling your document storage is a real cost.
Sign-in on a phone is a different problem. Typing a strong password on a phone with wet hands is miserable, and shared devices complicate everything. Device pairing — scan a QR code from the desktop application once, then use biometrics — removes most of that friction. It is also a cleaner security story, because you can revoke a device without changing anyone's password.
Do not let the app fork your business rules
This is the failure that costs the most and shows up the latest.
If the app implements its own validation — what makes a task completable, when a job can be closed, who can approve what — you now have two definitions of the same rule. They will agree at launch and disagree within a year, and the bug reports will be confusing because both systems are behaving "correctly".
The rules stay on the server. The app can mirror validation for a responsive experience, but the server decides, every time. That does mean the app has to handle being told "no" after the user has already tapped the button, which is a small amount of extra UI work and worth every minute of it.
What this typically looks like
An API layer over the existing platform, scoped to the field workflows. A Flutter or .NET MAUI app with a handful of screens, device-based authentication, background photo upload, and push notifications. The web application carries on untouched — the same projects, the same permissions, the same reports.
Nobody migrates. Nothing is rewritten. Office staff do not notice anything changed, which is exactly the point.