The work happens outside. The paperwork happens in the evening.
Engineers, drivers and field staff work on location and write it up afterwards. An app removes that second round: record it where it happens, even without signal, and sync it as soon as there is a connection again.
- Work orders come back on paper and someone retypes them.
- Photos of damage or handovers sit in WhatsApp instead of in the file.
- Tomorrow's schedule is still being phoned through tonight.
- Your people go to places without signal: basements, warehouses, rural areas.
- The customer's signature is on paper.
- The invoice only goes out once the work order is in, and that takes days.
- Material usage is estimated afterwards instead of counted on site.
- Your people type on a phone into a screen that was made for a desk.
Recognise two or more? Then the conversation is worth it.
When an app is needed — and when a website is enough
This is the question that can save you hundreds of euros a month, and almost no agency asks it. An app means app stores, version management and two platforms. Sometimes that is necessary. Often it isn't.
When the phone has to do more than display
Working offline. Without signal it has to keep going and sync later — a normal website can't do that reliably.
Really using the camera, GPS or a scanner: scanning barcodes, signing, recording a location with a report.
Notifications that arrive even when the app is closed. A driver doesn't check a website on his own accord.
When it can be done in the browser
Is it mostly reading and filling in with signal? Then a website on the phone is quicker to build, cheaper to maintain and updated instantly without an app store.
An app nobody installs is money thrown away. If your users are changing temp workers, the installation threshold is often fatal.
Want an app because it looks modern: don't. The maintenance burden stays, even if usage is disappointing.
What you get, and what we need from you
- One app for Android and iOS, built from the same code.
- Working offline with synchronisation, including agreements on what happens when two people change the same thing.
- Publication in the App Store and Google Play under your own developer account, in your name.
- A backend server that a website or another system can use as well.
- Test versions you can try out before anything goes to the store.
- A few people from the field team who want to think along and run test versions.
- Your own developer account with Apple and Google, or permission to request them.
- Access to the system the app talks to.
- Patience with Apple. Reviewing a new version sometimes takes days and nobody has any influence on that.
We are clear about this up front, because afterwards it is always an awkward conversation. Part of what we build is custom work for you. Another part consists of components we developed ourselves and use for more clients — and that is exactly why you don't pay again for every part. What falls under which agreement is in the contract before we start, not in an appendix you get at delivery.
If you want certainty in case we disappear, we arrange source code escrow: an independent third party holds the code and releases it to you when needed. For larger assignments that is a normal procurement requirement, and we cooperate with it.
How an app comes about
The order is different from a website: publishing takes longer than building. That is why we start the publication process early, while development is still going on.
-
01
One day · free of charge
Joining on location
A day out with an engineer or driver. Where does he stand when he has to fill something in, how much signal is there, is he wearing gloves. That shapes the design more than a wish list.
-
02
Arranging accounts and publication
Requesting developer accounts and preparing the app listing. This runs in the background because it can take weeks.
-
03
First version on real phones
Not in a simulator but on the engineer's own device, in the warehouse where the signal drops.
-
04
Trial with a small group
Five people really use it, next to the old process. That is how what goes wrong in practice comes to light.
-
05
Ongoing
Rolling out and keeping up
Publishing for everyone. After that there is maintenance: Android and iOS release versions every year that require changes.
What an app costs, and what it keeps costing
With an app, building isn't the only cost. Android and iOS release new versions every year, and an app that hasn't been touched for two years stops working at some point. So plan for maintenance from the start, not for a one-off investment.
We build with Flutter, where one codebase serves both platforms. That saves roughly half compared with two separate apps — and it is why an app is feasible for a mid-sized company these days.
An app needs yearly maintenance, even if nothing changes in what it does.
That is not a revenue model of ours but a requirement from Apple and Google. Whoever doesn't plan for it has an app that is no longer in the store two years from now.
Working without signal
Storing data locally and merging it later is the hardest part of an app. What happens when two people change the same work order? Those rules take time.
Android, iOS or both
With Flutter you build both at once. But testing has to happen on both, and Apple is stricter about what is allowed in its store.
Talking to your system
Just like a portal: the screen is the cheapest part. The connection to your planning or ERP is the work.
For those who want to check
This part is for your IT manager or for whoever will do the maintenance later. If you don't have one, you can skip it — it changes nothing about what you get.
Flutter
One codebase for Android and iOS, with its own rendering layer so it looks the same on both. Maintained by Google and mature enough for business apps.
Laravel
The backend is the same as in our other projects, so a website and an app can share the same server instead of each having their own.
Local storage with synchronisation
Changes are recorded locally and sent as soon as there is a connection, with explicit rules for conflicts.
Published under your own developer account with Apple and Google, not under ours.
What that looked like in practice
14
hours of retyping saved per week
Packing slips that book themselves
Technical wholesaler, 140 employees — PDFs from the mailbox are read, checked and created as orders in the ERP.
Laravel · RAG · ERP integration
6
weeks until the first integration went live
A core system from 2012, opened up again
Manufacturer in the Brainport region, 320 employees — an API layer next to the existing system, without production downtime.
Laravel · API · migration path
38.000
documents searchable with their source
The archive gives answers
Engineering firm, 85 employees — staff ask a question and get the answer with its source.
Laravel · embeddings · SSO
Half an hour costs you nothing
Tell us which process takes the most manual work. We will tell you honestly whether AI is the right answer — and sometimes the answer is: fix your integration first. Then you have that too, without an invoice.