# Field Service Mobile App: Offline-First Inspection, Work Orders & Time Tracking Field service companies with 10-100 technicians lose between $30,000 and $120,000 per year to paperwork inefficiency alone. The math is straightforward: if a technician spends 45 minutes per day on... ## Field Service Mobile App: Offline-First Inspection, Work Orders & Time Tracking Custom field service mobile app development with offline-first architecture — SQLite and Realm local databases, background sync, work order management, inspection forms with photo capture, GPS time tracking, customer signatures, and parts inventory — built for HVAC, electrical, plumbing, and industrial service companies where technicians work in basements, crawl spaces, and rural sites with zero cell signal. --- ## Our Process 1. **Workflow Audit and Requirements Mapping (2-3 Weeks)** — We ride along with your technicians. Not a conference room whiteboard session — actual field observation. We watch a senior tech run through a full service call from dispatch to completion: how they receive the job, what information they need before arriving, how they locate equipment on site, what forms they fill out, what photos they take, how they record parts and time, and how they close out the job. We do this across 3-5 different job types (emergency repair, scheduled maintenance, inspection, installation, warranty callback) because each workflow has different data requirements, approval chains, and documentation standards. Deliverable: a workflow specification document mapping every field, form, status transition, business rule, approval gate, and integration point — this becomes the functional blueprint for the app. 2. **Data Architecture and Sync Protocol Design (2 Weeks)** — Offline-first apps live or die on their data architecture. We design the local SQLite schema, define the sync protocol, establish conflict resolution policies for every entity type, and map the integration layer to your existing backend systems — whether that is an ERP like SAP, Oracle, or Sage, a CRM like Salesforce, an accounting system like QuickBooks, or a custom database. We define exactly which data syncs to the device (work orders, customer records, equipment history, parts catalog), how much historical data lives locally (typically 30-90 days), and what the sync prioritization order is. We prototype the sync engine against your actual backend and validate round-trip data integrity before writing a single screen. 3. **Flutter App Development — Core Workflows (6-8 Weeks)** — We build the app in Flutter, deploying a single Dart codebase to both iOS and Android. Development follows a workflow-priority sequence: work order lifecycle first (receive, start, complete), then inspection forms and photo capture, then time tracking and GPS, then parts inventory, then signatures and PDF generation. Each workflow is built against the local SQLite database from day one — there is no 'add offline support later' phase because the app is offline-first from the first commit. We deliver weekly builds to TestFlight and Google Play internal testing so your team can put the app in technicians' hands early and provide feedback on field usability — not just office demo usability. 4. **Sync Engine Integration and Backend Connectors (3-4 Weeks)** — With the core app workflows validated, we connect the sync engine to your production backend. This phase covers bidirectional sync testing with real data volumes (not 10 test records — thousands of work orders, hundreds of customers, full parts catalogs), conflict resolution validation with multiple technicians editing overlapping records, bandwidth testing on throttled connections simulating rural cellular, and integration testing with your ERP, CRM, and accounting systems. We specifically test the failure scenarios: what happens when a sync is interrupted mid-transfer, when the server is down for maintenance, when a technician's device runs out of storage, and when two offline technicians complete the same emergency dispatch. 5. **Field Pilot with Live Technicians (2-3 Weeks)** — We deploy the app to 3-5 of your technicians for a supervised field pilot. These are real jobs, real customers, real service calls — not simulated testing. Technicians run the app alongside their current process (paper forms or existing software) so we can compare output quality and identify gaps. We monitor sync performance, GPS accuracy, photo upload reliability, form completion rates, and time-per-task metrics. The pilot always reveals workflow edge cases that were invisible in discovery: unusual equipment configurations, customer-specific documentation requirements, regional compliance variations, and hardware-specific issues (specific Android devices with aggressive battery optimization that kills background sync). We fix everything before full rollout. 6. **Full Deployment, Training, and MDM Setup (1-2 Weeks)** — Rollout to all technicians with hands-on training (not a PDF manual). We configure mobile device management (MDM) for fleet-wide app distribution, automatic updates, remote device wipe for lost or stolen phones, and enforced security policies. Training is workflow-based: technicians learn by completing a mock service call on the app, not by reading documentation. We provide a 30-day hypercare period where our team monitors sync health, resolves field issues same-day, and makes rapid adjustments based on technician feedback. Post-launch support covers app updates, OS compatibility maintenance (iOS and Android release new versions annually that can break background processes), sync engine monitoring, and feature additions. --- ## Frequently Asked Questions ### How does offline-first actually work when technicians have no cell signal? Offline-first means the app never depends on a network connection to function. Every screen, every form, every workflow runs against a local SQLite database stored on the technician's device. When the technician opens a work order, they are reading from local storage — not making an API call to a server. When they fill out an inspection form, capture photos, log time, or collect a signature, all of that data writes directly to the local database. A background sync engine monitors network availability continuously. When connectivity is detected — WiFi, cellular, even a brief 30-second window of signal — the engine pushes queued records to the server and pulls down any new data (schedule changes, new work orders, parts updates). When the signal drops again, the app continues operating identically. Technicians cannot tell the difference between online and offline usage because the app was designed from the first line of code to never require a network connection for core functionality. The sync engine handles all the complexity invisibly: queuing, retry logic, bandwidth optimization, and conflict resolution all happen in the background without any technician interaction. ### What happens when two technicians or a technician and a dispatcher modify the same work order while offline? This is the core technical challenge of offline-first systems and the reason most off-the-shelf apps avoid true offline support. Our sync engine uses field-level conflict detection rather than record-level. When a sync occurs, the engine compares each field individually rather than treating the entire work order as a single blob. If a dispatcher changed the priority from Normal to Urgent while the technician changed the status from In Progress to Completed, those changes merge automatically because they modified different fields — no conflict exists. Genuine conflicts occur when two users modify the same field on the same record while both are offline. For example, if both a dispatcher and a technician add a note to the same work order while disconnected. In that case, the system preserves both versions, flags the record for manual resolution, and presents a side-by-side comparison in the app so a supervisor can merge or choose the correct version. In practice, genuine conflicts are rare — typically under 0.5% of all synced records — because field technicians and office staff modify different fields in normal workflows. We configure conflict resolution policies per entity type during the architecture phase, so your business rules determine how edge cases are handled. ### Why build custom instead of using ServiceTitan, Housecall Pro, or Jobber? ServiceTitan, Housecall Pro, and Jobber are excellent platforms for residential service companies with standard workflows — single-trade dispatching, flat-rate pricing books, and residential customer management. They are the right choice for a 5-15 person residential plumbing or HVAC company doing standard service calls. Custom development makes sense when your requirements exceed what these platforms can accommodate. The most common triggers we see are: industry-specific inspection forms that the platform cannot replicate (fire protection, elevator, medical equipment, industrial compliance), offline requirements because your technicians work in zero-signal environments (basements, industrial plants, underground utilities, rural areas), complex commercial pricing that does not fit residential flat-rate models (T&M with NTE caps, blanket purchase orders, tiered labor rates, multi-location MSAs), multi-trade coordination where a single work order involves electricians, plumbers, and HVAC technicians from different subcontractors, and legacy ERP integration where your accounting or operations system is not on the platform's supported connector list. The cost comparison over three years is often favorable for custom: ServiceTitan at $200-$400/month per technician for 20 technicians is $48,000-$96,000 per year in subscription fees alone, with no reduction over time and no code ownership. A custom app with comparable functionality runs $80,000-$200,000 to build, with ongoing maintenance of $2,000-$5,000/month — the breakeven point is typically 18-30 months. ### How much does a custom field service mobile app cost and how long does it take to build? A minimum viable field service app with work order management, one or two custom inspection form types, GPS time tracking, photo capture, customer signatures, and offline sync typically costs $80,000-$150,000 and takes 14-20 weeks from kickoff to production deployment. A full-featured platform with a drag-and-drop form builder, comprehensive parts inventory and truck stock management, multi-trade scheduling, subcontractor portal, customer-facing appointment tracking, and deep ERP integration runs $150,000-$300,000 and takes 5-8 months. The biggest cost variable is not the mobile app itself — it is the backend integration. Connecting to a well-documented modern API like QuickBooks Online adds 1-2 weeks of integration work. Connecting to a legacy ERP with no API (AS/400, Progress, older Sage or Viewpoint systems) adds 4-8 weeks and $30,000-$60,000 because we need to build middleware. The second major variable is the number of unique inspection form types. A single standardized form takes 1-2 weeks to build. Ten industry-specific form types with conditional logic, equipment-specific fields, and compliance-mandated layouts take 4-6 weeks. We scope every project individually because a 10-technician plumbing company and a 100-technician multi-trade industrial service company have fundamentally different requirements despite both needing a field service app. ### Can the app integrate with our existing ERP, accounting, and CRM systems? Yes, and this integration is typically the most valuable part of the project because it eliminates the double-entry that eats up office staff time. We integrate with all major field service-adjacent systems: ERP platforms (SAP Business One, Oracle NetSuite, Sage 100/300/Intacct, Viewpoint Vista, Microsoft Dynamics), accounting systems (QuickBooks Online and Desktop, Sage 50, Xero), CRM platforms (Salesforce, HubSpot, Zoho, Microsoft Dynamics CRM), and industry-specific platforms (Procore for construction, Corrigo for facilities management, ServiceChannel for retail maintenance). For systems with modern APIs, integration is straightforward — 1-3 weeks per system. For legacy systems with no API, we build middleware connectors using database-level integration, file-based import/export automation, or custom wrapper APIs. The integration layer is bidirectional: work orders created in your ERP automatically appear on technician devices, and completed work orders with labor, parts, and inspection data automatically flow back to your ERP for invoicing and cost tracking. The goal is zero re-keying — a technician completes a job on the app, and the invoice is ready to send in your accounting system without anyone in the office touching the data. ### What devices and operating systems does the app support? We build field service apps in Flutter, which compiles to native code for both iOS and Android from a single Dart codebase. The app runs on iPhones (iOS 15+), iPads, Android phones (Android 10+), and Android tablets. For field service, we specifically test on ruggedized devices that technicians actually carry — Samsung Galaxy XCover series, CAT phones, Kyocera DuraForce, and Zebra handheld devices — because these have hardware-specific behaviors (aggressive battery optimization, non-standard camera APIs, unique screen sizes) that consumer-focused apps never encounter. The app is optimized for one-handed operation on phone-sized screens (technicians have tools in the other hand) and for stylus input on tablets (for detailed inspection annotations). We also support barcode and QR code scanning using the device camera or integrated hardware scanners on Zebra and Honeywell devices. For companies that issue company-owned devices, we configure Mobile Device Management (MDM) through your existing MDM platform or set up a new one — this enables fleet-wide app distribution, enforced security policies, remote wipe for lost devices, and automatic updates without technician intervention. ### How does GPS time tracking work, and can it replace our current timekeeping system? GPS time tracking uses geofencing to automate clock-in and clock-out at job sites. During setup, we define a geofence (typically 100-300 meter radius) around each customer site address. When a technician's device enters the geofence, the app automatically records an arrival timestamp with GPS coordinates. When the device exits the geofence, it records a departure timestamp. Between arrival and departure, the app logs a GPS breadcrumb trail at configurable intervals (typically every 2-5 minutes) so you have a verifiable record of on-site presence. Drive time between job sites is tracked separately using continuous background location — the app calculates travel time from the departure geofence of one job to the arrival geofence of the next, categorizing it as travel labor automatically. All time entries categorize into labor types based on your business rules: regular hours, overtime (daily or weekly thresholds), double-time, travel, and administrative. For union shops, we implement the specific overtime calculations and classification rules from your collective bargaining agreement. The time data exports directly to your payroll system — ADP, Paychex, QuickBooks Payroll, or custom systems — in the exact format your payroll processor requires. For companies replacing manual timesheets, GPS-verified time tracking typically reduces disputed time entries by 80-90% and eliminates the end-of-week timesheet reconciliation process entirely. --- **Canonical URL**: https://freedomdev.com/solutions/field-service-mobile-app _Last updated: 2026-05-12_