iOS and Android
One codebase for both stores when it fits, native where the hardware or the performance demands it.
Country and language
Other markets: these available language versions show the same page.
Apps
Apps for teams in the field and for your customers, with the backend built alongside. Developed in Paris, published on the stores, source code delivered.
The problem
Technicians, drivers, inspectors and sales teams do the work somewhere else, then type it all in again at the office at seven in the evening. Photographs stay on a phone, signatures stay on paper, and the office learns what happened a day late. A mobile app is worth building when it removes that second entry, not when it simply puts your website in an icon.
We build apps for iOS and Android together with the backend they depend on, because the two decide each other. Screens are designed for one hand, in daylight, sometimes with gloves on: a small number of large targets, few fields, and defaults that are right most of the time. What is not needed in the field does not ship in the app.
Coverage is assumed to be bad. Data is captured offline, queued and synchronised when the signal comes back, with conflicts resolved by rules agreed during scoping rather than by the last person to press save. We publish on the App Store and Google Play under your own accounts, and you receive the source code for the app and the backend.
What you get
The visible app is half the project. The other half is the backend it talks to.
One codebase for both stores when it fits, native where the hardware or the performance demands it.
Forms, photos and signatures captured without a signal, queued locally and synchronised when coverage returns.
The server, the database and a documented REST API built with the app, not bolted on afterwards.
Token authentication, biometrics, roles per user, remote sign-out, and no shared password on a team device.
Barcode and QR scanning, geolocation, camera, PDF reports and push notifications when something needs attention.
Store listings, review process, phased rollout and updates handled under your own developer accounts.
How we work
Four stages, in this order. You sign off each one before the next starts.
We follow the job as it is done today, on site. Deliverable: a priced scope, the offline rules and the platform decision.
1 to 2 weeksClickable screens installed on your team's own handsets, so the size of a button is judged where it will be pressed.
2 weeksA build every two weeks through TestFlight and Play internal testing, used in the field while we keep building.
8 to 14 weeksStore submission, rollout, training, then updates and monitoring. Source code for app and backend is yours.
OngoingTechnology
Picked for what the app has to do in the field:
Example project
Reports were written on paper, photographed and retyped at the office the next morning. We built an app that captures the job, the photos and the customer signature offline, then pushes everything to the back office the moment a signal is available.
Budget
The figure depends on the number of screens, on offline requirements and on the backend behind it.
Indicative figure for a standard scope. Every quote is issued as a fixed price after the scoping phase, with no per-seat fee.
How it is priced
The price depends on the journeys to build, the systems to connect and the fact that two platforms have to be kept working. We scope first, then we put a fixed price on it.
After publication
A published app needs compatibility updates, or it eventually gets pulled from the stores. The contract is priced with the project.
FAQ
One shared codebase for both platforms in most business apps, which cuts the build and the maintenance roughly in half. We go native when the app leans hard on the hardware or on graphics performance. The decision is made at scoping, written down, and it changes the budget rather than the deadline.
If nobody works without a signal and you need no camera, scanner or push notification, a responsive website is cheaper and easier to update. We say so when that is the case. An app earns its cost when it removes a second data entry or works where coverage does not.
The app is published under your own Apple and Google developer accounts, so the listing, the reviews and the users stay yours. We set the accounts up with you, prepare the listings and handle the review process, including the rejections that are a normal part of a first submission.
Budget for at least two maintenance releases a year. Apple and Google change their requirements on their own schedule, and an app left untouched eventually stops being accepted. We quote maintenance separately and yearly, and you are free to have another team do it with the delivered code.
See also
Let's talk
Thirty minutes is enough to say whether an app is the right answer, and to give you an honest range before anything is designed.