Voor het veld

Native apps
voor mensen op locatie.

Apps voor monteurs, chauffeurs en inspecteurs. Offline-first, foto's en GPS uit de box, automatisch synchroniseren zodra er weer bereik is.

Offline is geen edge case, het is de werkomgeving.

Monteurs in een crawlspace, chauffeurs in een dode hoek van het bereik, inspecteurs op een dak in een industriegebied. Internet komt en gaat. Een app die alleen werkt op een redelijke verbinding verliest werkbonnen, foto's en handtekeningen, precies de momenten waarop je ze niet kunt missen.

Wij bouwen apps die offline doorwerken. Lokale SQLite slaat invoer op terwijl er geen bereik is. Een sync-queue verstuurt wijzigingen zodra het toestel weer in 4G of wifi staat. Conflicten worden afgehandeld via een gekozen strategie per scherm, last-write-wins waar volgorde logisch is, of een conflict-queue waarop de back-office handmatig review doet. Geen verloren werk.

Native is meer dan responsive web. Hardware-toegang (camera, GPS, NFC, barcode-scanner), push-notificaties die ook werken als de app dicht is, app-store-distributie zodat IT-beheer met MDM kan werken, en performance op oudere toestellen die in het veld de norm zijn. Een mobiele website doet dat niet.

Veldwerk app Lokale SQLite Sync queue Backend API // offline werkt door // sync als bereik
// wat_we_bouwen

Wat wij bieden

Bouwstenen voor apps die in het veld doorwerken.

Werkbonnen en orderafhandeling

De monteur ziet zijn ronde, vult op locatie de bon, foto bij oplevering, klant tekent op het scherm. De backoffice ziet het werk binnenkomen zodra het toestel weer bereik heeft.

Foto-uploads met metadata

Foto's krijgen automatisch GPS-coördinaten, tijdstempel en koppeling aan het juiste dossier. Geen losse fotomappen meer, alle context staat erbij.

Barcode en NFC scannen

Voorraad, materiaal, asset-tags. Scan, registreer, koppel aan order. Werkt offline en synct later.

GPS en route

Locatie van het werk, geoptimaliseerde route langs de stops, automatische registratie van aankomst en vertrek voor declaratie. Privacy-instellingen per medewerker.

Push-notificaties

Spoedklus naar de dichtstbijzijnde monteur, statuswijziging vanuit kantoor, herinnering voor periodieke inspectie. Werkt ook bij gesloten app.

Sync-protocol dat het werk vasthoudt

Twee monteurs die offline aan dezelfde order werken, drie wijzigingen tegelijk op één werkbon, een toestel dat een week zonder bereik is geweest, het sync-protocol pakt het op met last-write-wins, conflict-queue of merge-per-veld, afhankelijk van wat het veldproces vraagt.

// aanpak

Zo werken we

01

Discovery in het veld

We lopen letterlijk een ronde mee met je team. Wat kost nu tijd op locatie, waar zit slechte ontvangst, welke handelingen frustreren, wat schrijven mensen nu nog op papier. De app ontwerpen we voor die werkelijkheid, niet voor een kantoor-mockup.

02

Architectuurontwerp

Offline-first datamodel, sync-strategie per scherm en conflictresolutie vóór de eerste UI. Welke data leeft alleen in de app, welke leeft op het backend, welke loopt heen en weer. Hardware-integraties (camera, GPS, NFC) worden in deze fase gemapt op concrete API's per platform.

03

Bouw met device-tests

Niet alleen simulator. Echte iOS- en Android-toestellen, slechte 3G, vliegtuigmodus, bijna lege batterij, oude OS-versies. CI draait per release op een matrix van toestellen, als de app op een vier jaar oude Samsung niet vlot opent, weten we het voordat een monteur het ervaart.

04

Gefaseerde uitrol

Een paar collega's eerst, twee weken in productie, feedback verwerken, dan breder. App-store-publicatie via je eigen developer-accounts, MDM-distributie als dat past bij hoe IT je vloot beheert.

// stack

Waarmee we werken

Backend en sync-strategie staan vast, app-stack-keuzes maken we per project.

App-stack

  • Cross-platform framework [?]
  • Native modules waar nodig (Swift / Kotlin)
  • SQLite voor lokale storage
  • ORM en state-management [?]

Backend en sync

  • Laravel (PHP 8.4) met API-resources
  • Laravel Sanctum voor token-auth
  • REST-sync met cursor-based pagination
  • Last-write-wins of conflict-queue per scherm

Distributie en monitoring

  • Apple Developer Program + Google Play Console
  • Beta-distributie [?]
  • Push [?]
  • Sentry voor crash-rapportages
  • App-analytics [?]
// scenarios

Hoe dit er in de praktijk uitziet

Installatiebedrijf met monteurs op locatie

Monteurs krijgen 's ochtends hun ronde op de telefoon, voltooien werkbonnen offline, maken foto's bij oplevering en laten de klant op scherm tekenen. Materiaal wordt via barcode afgeschreven van een lokale voorraadlijst. Sync gebeurt automatisch zodra het toestel weer in 4G is. Wat eerst handgeschreven werkbonnen waren die 's avonds in de backoffice werden ingevoerd, verschijnt nu live in de planning.

Transportbedrijf met chauffeurs en stops

De chauffeur ziet zijn rit, klant tekent voor ontvangst, foto bij beschadiging gaat direct naar dossier. GPS registreert aankomst en vertrek voor declaratie. Disponent stuurt last-minute aanpassingen via push die ook werken als de app dicht is. Geen briefjes meer in het dashboard, geen telefoontjes "ben je er al?".

Inspectiebureau met inspecteurs

Per inspectie een gestructureerd formulier op tablet, foto's gekoppeld aan checklist-items, NFC-tag scannen voor asset-identificatie. Offline werkt door op locaties zonder bereik (kelders, machineruimtes, daken). Het rapport wordt automatisch gegenereerd zodra de inspectie compleet is en synct met de backoffice voor controle en facturatie.

Veelgestelde vragen

Hoe weten we welk framework past bij ons project?
Beide grote cross-platform frameworks (React Native en Flutter) leveren productie-kwaliteit apps. React Native als je team al React kent en je code wilt delen tussen web en mobile; Flutter als je de meest consistente UI op beide platforms wilt en de Dart-leercurve geen blokkade is. We leggen de keuze vast in Discovery, vanuit teamervaring, deelbaarheid van code en het type interacties dat de app moet ondersteunen.
Wat als één veldmedewerker een week zonder bereik werkt?
Dat is precies waar offline-first voor bedoeld is. De app blijft werken, alle invoer wordt lokaal opgeslagen, en zodra er bereik is loopt de queue netjes leeg. Voor extreme gevallen ontwerpen we de app zo dat ook intermediair gebruik niet leidt tot dataverlies, periodieke check op queue-grootte, waarschuwing bij geheugen-issues, en een handmatige forceer-sync-actie voor de momenten dat een medewerker zelf wil ingrijpen.
Hoe gaat de app om met conflicten als twee mensen offline werken aan dezelfde order?
Drie strategieën, afhankelijk van de business-regels per scherm. Last-write-wins als de laatste editor logisch is. Een conflict-queue waar de backoffice handmatig review doet, voor velden waar je niet zomaar mag overschrijven. Of merge-per-veld waar dat technisch kan, bijvoorbeeld foto's en notities die elkaar niet uitsluiten. We leggen de strategie per scherm vast in het architectuurontwerp.
Hoe distribueren jullie de app?
Voor productie via de App Store en Google Play Store onder jouw developer-accounts. Voor intern beta-testen via TestFlight (iOS) en Play Console interne tracks (Android), eventueel via Firebase App Distribution of EAS Build als de release-cadans dat vraagt. Bij MDM-omgevingen (Microsoft Intune, Jamf) leveren we een installer-package dat IT direct kan uitrollen.
Werkt de app ook op tablets?
Ja, en voor inspecties en gestructureerde formulieren werkt het meestal beter dan op telefoon. We ontwerpen responsive: dezelfde codebase, schermen passen zich aan op tablet-formaat met meer informatiedichtheid waar dat zin heeft.
Hoe lang duurt een native-app project?
Een eerste werkende versie met de twee tot drie kern-flows is meestal in 12 tot 16 weken klaar, exclusief app-store-review (1 tot 2 weken, buiten onze invloed). Latere modules of platform-uitbreidingen voegen we incrementeel toe in sprints van twee weken.
+ + + +

// volgende_stap.execute()

Een app voor het veld?

Vertel waar je team werkt en wat ze nu op papier of mondeling regelen, dan ontwerpen we de offline-flow en sync-architectuur.