Mobile app development
The biggest mistake teams make with a mobile app is treating it as a separate project from the web app. By the time it ships, the web app is two versions ahead and the iOS bundle is a screenshot of last quarter. We build both from one codebase.
What's included in Mobile apps.
Field sales, site engineers, warehouse staff, delivery drivers: none of them sit at a desk and none of them have reliable 4G. Before we design anything, we document how they record the work today (a paper form, a WhatsApp photo, a call back to the office) and agree what the app must capture. It has to work offline, sync when the signal comes back, and never silently lose what was typed in the lift.
Field-sales teams, distributors with site visits, manufacturers with multi-warehouse operations, delivery and logistics ops, and internal IT teams shipping a companion app for an existing web product.
- 01
Offline-first
Local SQLite or Realm, a sync queue with conflict resolution, and a visible 'sync status' badge so the user knows when their data has actually reached the server.
- 02
Camera + geotag capture
Photo capture with timestamp + lat/lng burned in, supports site visits, delivery proof, attendance, and field-audit photos. Compressed before upload so it works on a 2G connection.
- 03
Push notifications
FCM on Android, APNs on iOS, with topic-based subscriptions and a deep-link router so tapping a notification opens the exact screen it refers to.
- 04
Shared code with web
Business logic, types, and API client live in a shared package, so a rule changed on the web behaves the same way on mobile.
- 05
PWA option
When a native app is overkill, we ship a Progressive Web App that installs to the home screen, works offline, and gets push notifications on Android without an app-store submission.
- 06
Store + MDM
Play Store and App Store submissions, plus enterprise MDM packaging (Intune, Hexnode) when the app is for internal use only.
From paper field forms to an offline-first app.
Follow the field team
We look at how visits, deliveries and site checks are recorded today, from paper forms and WhatsApp photos to calls back to the office, and note where the signal drops. What the app must capture, and whether it ships as native or a PWA, is agreed in writing.
Build for weak signal
We build the app on a codebase shared with your web system, with local storage, a sync queue and geotagged photo capture. Then we put early builds on the phones your staff actually carry and test them in the basements, lifts and yards where coverage fails.
Roll out to devices
We publish to the Play Store and App Store, or package the app through your MDM for internal use, and train supervisors and field staff on the screens they will use. After rollout we track sync failures and keep the app current with each OS release.
Questions about Mobile apps.
- Can a mobile app replace paper forms and WhatsApp photos from our field team?
- Yes. Before designing anything, we document how your field sales, site engineers, or warehouse staff record the work today, whether that is a paper form, a WhatsApp photo, or a call back to the office. The app then captures the same information with timestamped, geotagged photos, works offline, and syncs when the signal returns, so nothing typed in a basement or a lift is silently lost.
- Will the field app sync with our CRM, ERP, or web portal?
- Yes. We build the mobile app and the web app as one codebase, with business logic, types, and the API client in a shared package, so a rule changed on the web behaves the same way on mobile. Visit reports, delivery proofs, and orders flow into the same backend as your CRM or ERP. Links to Tally or other existing systems are mapped during the requirement study.
- How do you decide between a native app and a PWA for our team?
- We decide it in the requirement study, based on the devices your team carries, how poor the connectivity is, and whether the app is for staff or customers. When a native app is overkill, a Progressive Web App installs to the home screen, works offline, and receives push notifications on Android without an app-store submission. The choice, the screens, and the timeline are agreed in writing before design begins.
- Who handles app store submission, device rollout, and updates after launch?
- We handle Play Store and App Store submissions, or enterprise MDM packaging through Intune or Hexnode when the app is for internal use only. Before go-live we test on the phones your team actually uses, in the places where the signal drops, and train supervisors and field staff. After launch we stay on for support, and a monthly maintenance retainer covers OS updates, fixes, and new features.
Tell us what's slowing you down.
A 30-minute discovery call. We map the process, point out the easy wins, and outline a clear plan (no obligation).