Conditions of use
Where, when and with what in their hands someone opens the app. That drives screen contrast, button size, voice or scan input and how many taps it takes to finish.
A timber merchant in the Savinja valley buys logs from private woodland owners. Its measurers stand on a forest track recording each log's diameter and length, write the cubic volume into a notebook, and on Monday somebody in the office keys it into Excel and then again into Pantheon. There is no coverage down in the ravine, hands go stiff in winter, and the owner wants paying promptly. Designing an app for that job, we do not start by picking a framework. We start with the setting: glare on the screen, rain, gloves, one free hand, a battery that must last till dusk. Button size, input method and sync behaviour follow from there. A Bluetooth calliper can send the diameter straight into the app, the app works out volume, and the owner receives a statement the same day. We will also be frank when an app is overkill. If people open it only a handful of times a year, a phone-friendly website or a progressive web app (PWA) is almost always cheaper and good enough. Remember that an app costs not only its build but also a round of updates every time Apple or Google ship a new OS.
The phone is the tip of the iceberg. Beneath it sit a server, an office dashboard, an ERP link and operating systems that change every year.
Where, when and with what in their hands someone opens the app. That drives screen contrast, button size, voice or scan input and how many taps it takes to finish.
A PWA for occasional use and simple forms, Flutter or React Native for daily work, Swift and Kotlin when the job reaches deep into the hardware. The choice comes with a table of build and upkeep costs.
Everything is saved locally and pushed upstream when coverage comes back. Simultaneous edits to one record are settled by a rule agreed in advance, and the person affected is shown the outcome.
Camera for photos and paperwork, barcodes and QR codes, NFC, Bluetooth measuring tools, GPS. Tested on the handsets your crew actually carries, rugged models and bargain phones included.
Entries land in Pantheon, Minimax, SAP Business One or an in-house system, and back-office staff plan, approve and report from a browser-based console.
Staff-only builds reach phones through Microsoft Intune, Apple Business Manager or a private Google Play channel. Customer-facing apps go out under store accounts that your company owns.
Anonymous crash data via Firebase Crashlytics or Sentry, a changelog for every build and regression testing whenever Apple or Google announce a major OS update.
An installable build reaches the field early. What looks fine at a desk often behaves differently in sunshine or drizzle.
Remote interviews with the crew and phone footage you send us, showing terrain, handsets, pace and typical errors.
A few crew members install it via TestFlight or an internal Play Console test and use it on genuine jobs.
For several weeks paper and app run in tandem; afterwards we sit down with you and reconcile any discrepancies.
Rollout to everyone, short video guides and scheduled upkeep around new operating system releases.
Test outdoors, not in the office. An app meant for the field should be tried wearing gloves, in daylight, on whatever phone your least patient colleague keeps in their pocket. Five minutes of that reveals more than an hour of demos on a large monitor, and fixes are still cheap at that stage.
Not if only staff use it. Apple supports private distribution for organisations through Apple Business Manager, while Android devices can receive it from a private Google Play listing or straight from Intune. Outsiders will not find it.
Developer accounts with Apple and Google registered to your business. For organisations, Apple generally also asks for a D-U-N-S number. We help with registration, and the accounts remain yours.
Position data identifies people, so you need a stated reason and must tell employees about it. We usually capture coordinates only at the moment a task is logged, never in the background and never after the shift ends. Whether that satisfies GDPR and ZDR-1 is for your lawyer to assess.
Yes, provided we plan for it from the start. Early on we agree a list of supported devices and include each one in testing.
Keeping a typical business app compatible with each year's OS releases and pushing it through store review again tends to cost a handful of days annually, at €50 per hour plus VAT. A monthly pool of hours suits you better if fresh features are planned.
Who will use it, where and how often? We will recommend the right format and a sensible first-release scope.
Enquiry received
An engineer will write back no later than the following working day. Faults that leave your staff unable to work are always looked at first.
No town by that name here. Check the letters, or settle for the nearest larger place. Our engineers work only over the internet, so Kočevje and Koper get precisely the same treatment.