One app for iOS and Android, built once.
We build apps where the phone does something a website cannot: camera, location, notifications that reach the pocket and work that carries on without a signal. One codebase for both systems, connected to the data you already hold.
- One codebase, both systems
- Published in both stores
- Fixed price after the consultation
Four signs that the phone really adds something here.
Customers who keep coming back
Ordering, booking, checking a balance: when the same people do the same thing several times a month, an icon on the home screen saves a few steps every time. Twice a year, it does not.
Staff out on the road
Building sites, delivery vans, maintenance calls. The app keeps working in a dead spot and syncs as soon as the signal returns, instead of someone typing the day up again in the evening.
Photos, scans and signatures
A report with a picture, a label scanned, a handover signed on the spot. It happens where the work happens, on the device that is already in the pocket.
Alerts that have to land
A push notification appears on the lock screen; an email waits in an inbox behind fifty others. For last-minute changes, that is the whole difference.
From the first sketch to an app that sits in the stores and stays looked after.
One codebase, two systems
iPhone and Android from the same project, with the same functions and the same look. A change is built once and goes to both stores.
Camera, location and sensors
Scanning codes, taking photographs, following a route, talking to devices over Bluetooth. This is the part a website can only half do.
Working without a signal
The app stores locally and sends everything on once the network is back. Anyone working in a basement, a tunnel or out in the hills notices nothing.
Push notifications
A message to everyone, to one group or to a single person, triggered by your software rather than by hand. The user decides which of them to receive.
Sign-in and data protection
Signing in by face or fingerprint, encrypted storage on the device and clear rules on what is deleted at sign-out. Apple checks this before it lets an app through.
Release and maintenance
Store accounts in your name, submission, review by Apple and Google. Then the ongoing care: new system versions, error monitoring, small improvements.
For your customers, for your people, or both
An app facing outwards and an app facing inwards are two different jobs, even when they share the same technology. We build both, often from one codebase and on one server.
The app for customers
Ordering, booking appointments, checking orders and balances without signing in from scratch every time. It sits publicly in the App Store and on Google Play.
The app for your team
Reports, checklists, rounds, materials and hours, recorded where the work happens. Internal apps need not be public: they can be distributed to your own devices only.
Both on the same foundation
The customer books in the evening, the engineer sees it in the morning. One set of data, one sign-in system, no second version of the truth for somebody to reconcile by hand.
The app is not an island
An app that keeps its own records becomes the seventh place where something is written down. It earns its keep only when it hangs off the systems you already work with.
The same accounts as the website
Anyone already registered online signs in to the app with the same details. No second customer list quietly drifting apart from the first.
Connected to your systems
Through APIs to accounting, till, stock or online shop, whether that is Bexio, Abacus, Sage or a database of your own. The figure is entered once and agrees everywhere.
Where the data sits
The server can stand in Switzerland. Only what is needed for working offline stays on the device, and it goes again when the user signs out.
App or website?
The question that comes before the budget. We build both, but they do not suit the same job.
Installing and getting in
App in the stores
Through the App Store and Google Play, then an icon on the home screen.
Web application in the browser
A link is enough, nothing to install, everyone is on the same version at once.
Push notifications
App in the stores
They land on the lock screen, even with the app closed.
Web application in the browser
Possible on Android; on the iPhone only if the site has been added to the home screen.
Camera, location and sensors
App in the stores
Full access: scanning, photographs, location in the background, Bluetooth.
Web application in the browser
Camera and location usually yes; anything deeper, or running in the background, no.
Working offline
App in the stores
Carries on, stores locally and syncs later.
Web application in the browser
Short gaps can be bridged; a whole day without a network becomes awkward.
Upkeep and updates
App in the stores
Two systems that expect to be kept current each year, plus review by the stores.
Web application in the browser
One version for everyone: change it once and they all have it immediately.
Being found
App in the stores
In the App Store and on Google Play, but not in Google search results.
Web application in the browser
Findable through Google, but with no fixed place on the home screen.
Honestly: in many cases a well-made web application is enough and costs less to keep running. If that is true for you, we will say so at the initial consultation rather than sell you an app.
Four stages, and after each one you know where you stand.
- 1
Conversation and scope
Free and without obligation. We look at what the app has to do, who will use it daily and whether an app is needed at all. It ends with a list of functions for the first version.
- 2
A prototype you can tap
Every screen as a mock-up you can tap on your own phone before a line of code exists. Changing something here costs a conversation; changing it later costs development.
- 3
Development in stages
We build in two-week stages. You install the current version on your device as a test build, and your feedback goes straight into the next stage.
- 4
Release and maintenance
We set up the developer accounts in your name and submit the app to Apple and Google. After that we keep it in step with the systems, with ongoing maintenance if you want it.
The choice follows your project, not the fashion of the year.
App
React Native, Flutter, Swift, Kotlin
Server
Node.js, Python, .NET
Data
PostgreSQL, Redis, file storage
Release
App Store Connect, Google Play Console, push services, error monitoring
When we advise against an app
- If what you mainly want is to be found: the search results show a website, not an app.
- If there is no reason to come back often: what people need twice a year gets deleted from the home screen.
- If the hope is that the store will bring customers by itself: the apps found there are the ones people already know.
- If nobody can look after it after launch: Apple and Google change something every year, and a neglected app is eventually dropped.
What does an app cost?
It depends on how many screens and functions the first version has, and on whether there is already a system behind it that we can connect to. That is why we do not name a figure before we know. At the free initial consultation we settle the scope, and you then receive a fixed price for exactly that scope. Many start with a first version that does a few things well and extend it later.
Free initial consultationDo we really need an app, or is a website enough?
Ask what the phone adds. Camera, location, push notifications, working without a signal and daily use all argue for an app. If it is about informing people, taking enquiries and being found, a website is quicker to have and cheaper to keep. We will tell you at the initial consultation which of the two adds up in your case.
Does the app have to be built twice, for iPhone and Android?
No. With React Native or Flutter both come from the same codebase, and the user cannot see the difference. We propose purely native Swift or Kotlin only where it genuinely counts, such as demanding graphics or deep access to the hardware.
How does the app get into the App Store and Google Play?
The developer accounts belong to your organisation; we set them up with you and handle the submission: description, images, privacy details. Both stores review every app before release and can ask for changes. That is part of the job, and we stay with it until the app is out.
Can the app talk to our existing software?
As a rule yes, through APIs. Website accounts, jobs from the ERP, stock levels, accounting: the app becomes the front end for what you already have. Where a system offers no API, we say beforehand what is possible and what is not.
What happens after launch?
Apple and Google release new system versions every year, and an app that does not keep up eventually falls out of the stores. We take on the ongoing care if you wish, monitor errors and build in improvements. The code and the store accounts are yours: you can hand them to somebody else at any time.
Tell us what your people need while they are out.
At the free, no-obligation initial consultation we look at what the app has to do and tell you honestly whether it needs an app or whether a website will do. We reply within 24 hours.
Book an initial consultationJust a quick question? The AI assistant in the bottom right answers straight away.
Ready for the summit?
Tell us about your project. We reply within 24 hours with an honest assessment. Free and without obligation.
hallo@aurphi.chAurPhi MoukrimMarktstrasse 18, 8853 Lachen SZ, SwitzerlandPostal address, no walk-in service. Appointments by arrangement.