Field and operations apps
For people working away from a desk and often away from signal. Offline-first is the architecture, not a feature.
Delivery confirmation captured in a basement and synced when the van resurfaces.
Capability
Mobile App Development Services
iOS and Android from one Flutter codebase, or native where the hardware demands it — shipped to both stores with the review process handled, offline behaviour designed rather than discovered, and crash reporting from day one.
From $9,000 · 6–12 weeks · fixed scope, agreed in writing
- To both app stores
- 6–12 weeksTo both app stores
- iOS and Android, via Flutter
- One codebaseiOS and Android, via Flutter
- Designed, not discovered in testing
- Offline firstDesigned, not discovered in testing
- Crash and adoption reporting
- Day oneCrash and adoption reporting
What your team gets
What is actually delivered
Not a strategy deck. A running system, the permissions around it, and the code in your repository.
- Shipped to the App Store and Play Store, with the review process handled
- One Flutter codebase for both platforms, or native where the hardware requires it
- Offline behaviour designed up front, not discovered during testing
- Push notifications, deep links and over-the-air updates where they apply
- Crash reporting, analytics and release automation from the first build
- Full source code, signing setup and store accounts in your name
What we build
Six kinds of app we build
The technology choice follows the job. Most of these are one Flutter codebase; two of them are not, and we will say which.
Customer and member apps
Accounts, self-service and notifications, backed by the same system your staff use so nobody disagrees about the record.
A member app for renewals, documents and event registration.
Marketplace and booking apps
Two-sided flows with payment, scheduling and the notification choreography that makes them feel reliable.
Sports field booking with availability, payment and reminders.
IoT and device companions
Apps that talk to hardware over Bluetooth or a local network, where the protocol and the firmware are part of the project.
A recycling app syncing with collection hardware and an eco-coin wallet.
Internal tools
Small, sharp apps for one team doing one job repeatedly, where speed of use beats breadth of feature.
Stock counting on the warehouse floor with a barcode scanner.
AI-assisted apps
On-device or API-backed intelligence inside a mobile product, with the cost and latency budget worked out before it ships.
A finance agent shipped to web, iOS and Android on a customised model.
How we build it
The decisions that decide whether an app survives its first month
Most mobile projects fail after launch rather than before it: an app that cannot be updated without a rewrite, that loses data when the signal drops, or that nobody can debug because there is no telemetry. These five decisions are aimed squarely at that.
- 01
Pick the platform honestly
Flutter for most things — one codebase, two stores, genuinely native performance. Native when the app lives on a hardware API, needs deep platform integration, or is a widget-and-background-task product. We recommend native when it is right, which costs us margin.
- 02
Design for offline first
The device writes locally and queues an outbox that drains when connectivity allows. Retrofitting this is one of the most expensive changes in mobile, so it is decided in week one whether or not anyone expects poor signal.
- 03
Own the release pipeline
Automated builds, signing, and both store submissions from the start. Store review is a schedule risk that has to be discovered in week two rather than in the week you planned to launch.
- 04
Instrument before launch
Crash reporting, adoption and the three funnels that matter, live in the first build. An app without telemetry cannot be improved, only guessed at.
- 05
Plan for version skew
Users do not update. The API is versioned, old clients keep working, and there is a supported route to force an upgrade when it is genuinely necessary.
Flutter or native
Flutter suits most business apps: one team, one codebase, both platforms, and performance indistinguishable from native for interface-led products. Native wins when the app is built around platform hardware APIs, needs extensive widgets or background processing, or where a single platform is the whole audience. We make the call on the app rather than on what is cheaper for us to staff.
- Flutter
- Most business and customer apps.
- Swift / SwiftUI
- Deep iOS integration, widgets.
- Kotlin / Compose
- Android-first, background work.
- Hybrid
- Flutter with a native module where needed.
Offline and sync
Offline-first means the app is authoritative locally and reconciles later. That forces real decisions: what happens when two devices edit the same record, how conflicts are resolved, and what the user sees while a write is pending. We settle those in design, because discovering them in testing means rebuilding the data layer.
- Local store
- Drift, Isar or SQLite.
- Outbox
- Queued writes, retried in order.
- Conflict rules
- Decided in design, not in a hotfix.
- Pending state
- The user always knows what is unsent.
Store review, planned for
App Store review is a real schedule dependency, and the rejections that cost time are predictable: account deletion, privacy labels, permission justification, sign-in requirements. We submit a build early to surface them, rather than meeting them for the first time in the week you intended to launch.
Where it lands
What this looks like in your industry
Distribution and logistics
Delivery and proof-of-delivery apps that work without signal and sync when they can.
Sustainability and recycling
Consumer apps with wallets, rewards and IoT sync to collection hardware.
Institutions and membership
Member apps for renewals, documents and events, sharing the portal’s records.
E-commerce and retail
Stock counting and pick verification on the floor, with a scanner.
Healthcare and pharmacy
Field data capture where records must be complete and attributable.
Hospitality and restaurants
Floor and kitchen apps that stay in step with the operations system.
Technology
What we build agents with, and what we connect them to
We pick the boring option unless there is a reason not to — the framework is the part most likely to be abandoned before your system is.
- Cross-platform
- Flutter
- Dart
- Riverpod
- Drift
- Isar
- Native
- Swift
- SwiftUI
- Kotlin
- Jetpack Compose
- Core Data
- Room
- Backend and sync
- Django REST Framework
- FastAPI
- Firebase
- Supabase
- WebSockets
- GraphQL
- Device and hardware
- Bluetooth LE
- Camera and ML Kit
- Geolocation
- Secure storage
- Biometrics
- Release
- Fastlane
- Codemagic
- GitHub Actions
- TestFlight
- Play Console
- Observe
- Sentry
- Firebase Crashlytics
- Firebase Analytics
- PostHog
How the engagement runs
Five phases, each with something you can hold
Every phase ends in a named deliverable. You can stop after any of them and keep what has been built.
- 01Week 0
Discovery call
Who uses it, where, and on what connection. Those three answers usually decide Flutter versus native and how much of the budget goes on sync.
DeliverableA written next step, free - 02Weeks 1–2
Flows and architecture
The core flows drawn including the offline and error states, the platform decision made, and the data and sync model agreed.
DeliverableFlows, platform decision, sync design - 03Weeks 3–8
Build
Fortnightly builds to TestFlight and internal testing, so real people use it on real devices long before launch. A store submission goes in early to surface review issues.
DeliverableTestable builds every fortnight - 04Weeks 9–10
Hardening
Device matrix testing, offline and poor-connection scenarios, crash triage, performance on the low end of the range rather than the top.
DeliverableRelease candidate, crash-free session rate - 05Weeks 11–12
Store launch
Submission to both stores, listings and privacy labels, release automation handed over and the accounts in your name.
DeliverableLive on both stores, source code, signing handover
Why Devs Core
Six reasons that are checkable
We recommend native when it is right
Even though one Flutter codebase is cheaper for us to staff. The app decides, not our margin.
Offline is designed in week one
Retrofitting sync is one of the most expensive changes in mobile. We decide it before any screen is built.
Store review is planned for
An early submission surfaces the predictable rejections — account deletion, privacy labels, permissions — before they are on your critical path.
Telemetry from the first build
Crash reporting and adoption analytics live before launch, because an app without them can only be guessed at.
The accounts are yours
Store accounts, signing keys and source code in your name. You are never locked out of your own app.
Tested on the low end
Performance verified on the cheaper half of the device range, which is where most of your users actually are.
Questions
Mobile App Development — the questions we get asked
Should we build with Flutter or native?
Flutter suits most business and customer apps: one codebase, both platforms, and performance indistinguishable from native for interface-led products. Native is the better choice when the app is built around platform hardware APIs, needs extensive widgets or background processing, or when one platform is effectively the whole audience. We make that call on the app rather than on staffing convenience.
How much does mobile app development cost?
Mobile app development starts at $9,000 for a fixed scope over six to twelve weeks. The main variables are the number of distinct user roles, whether offline sync is required, and whether the app talks to hardware — any of which can move the number significantly.
How long does it take to get into the app stores?
Six to twelve weeks from start to live on both stores for a first version. Store review itself is usually days rather than weeks, but the rejections that cost time are predictable — account deletion, privacy labels, permission justification — so we submit a build early to surface them rather than meeting them at launch.
Does the app work without an internet connection?
If your users need it to, yes — and we decide that in week one. Offline-first means the app writes to a local database and queues an outbox that drains when connectivity returns, with conflict rules and pending states designed rather than improvised. Retrofitting this later means rebuilding the data layer, which is why it is not a later decision.
Who owns the app store accounts and signing keys?
You do. Apps are published under your developer accounts, signing keys are handed over, and the source code is in your repository. You are never in a position where your app cannot be updated without us.
Can you take over an existing app?
Usually. We start with an assessment of the codebase, the release setup and the crash data, and report what is worth keeping and what it would cost to take on — before agreeing to own it. An app with no telemetry and no release automation is a bigger job than it looks.
Do you build apps with AI features?
Yes, and the important part is the budget rather than the model. On-device inference is free per run but constrained; API-backed inference is capable but has a cost and latency per call that has to survive real usage. We work that out before it ships rather than after the first bill.
What happens after launch?
Crash reporting and analytics are live from the first build, so the first weeks are measured rather than guessed. Ongoing maintenance is available and never required — the release pipeline, signing and source are yours, and another team could take over.
Tell us which process is costing you.
Thirty minutes, no preparation, no deck. You describe what keeps going wrong and we tell you whether AI is the answer — including when it is not.
Prefer email? contact@devs-core.com