Mobile apps people keep on their phone.
An app earns its place on a home screen or it gets deleted in a week. That is a higher bar than a website has to clear, and it changes how the work is done: fewer features, better ones, and a first launch that answers a real need instead of listing everything you could imagine building.
Native or cross-platform — the choice that decides your budget
This is the first question and it deserves a straight answer rather than a preference.
Cross-platform
means one codebase running on iOS and Android. You pay once for most of the work, you ship to both stores at the same time, and every fix lands everywhere. For the large majority of business apps — catalogues, bookings, accounts, dashboards, content — the result is indistinguishable from native, and the saving is substantial.
Native
means two separate codebases. It costs more and takes longer, and it is the right call when the app leans hard on the device itself: heavy camera work, background processing, tight hardware integration, or performance at the edge of what a phone can do.
We do not sell one as inherently better. We ask what your app does, and one of the two becomes obviously right.
What we build
Customer-facing apps.
Booking, ordering, browsing, accounts, loyalty. The app is a sales channel and it is judged on how quickly someone gets what they came for.
Field and internal tools.
Apps for teams that work away from a desk — inspections, deliveries, stock, reporting. These live or die on offline behaviour: a technician in a basement still has to be able to work.
Companion apps.
A mobile extension of a platform you already run. Most of the value here is in the synchronisation, not the screens.
Connected-device apps.
Bluetooth, sensors, hardware control. Half the effort goes into what happens when the connection drops, which is the part demos never show.
The part most projects underestimate
Publishing is not the end of the work; it is a stage with its own rules.
The stores review your app.
Apple in particular rejects for reasons that surprise first-time publishers — a permission explained too vaguely, a login flow that offers no way out, a mention of payment outside their system. We prepare for it rather than discover it.
Accounts belong to you.
Your Apple Developer and Google Play accounts are yours, opened in your name. An agency that publishes under its own account holds your app hostage without anyone intending it.
Updates are a routine, not an event.
Both platforms release a major version every year, and each one deprecates something. An app nobody maintains stops working eventually — not because it was badly built, but because the ground moved.
How we work
A call, first.
We start with a free 30-minute call to establish what the app has to do and, more usefully, what it does not have to do in its first version.
Then a plan, then increments.
Then a written plan with phases. Then visible increments — you install builds on your own phone while the work is in progress, which is worth more than any screenshot.
Then handover.
At handover you get the code, the store accounts, the signing keys and a walkthrough. What comes next is a separate conversation, not a lock-in.
Proof
Our web platforms already carry the reasoning a mobile app needs — Dune Riders for booking and availability, Villa Aura for reservation flows, Verdia for structured catalogues. The domain logic is the same; the surface changes.
What it costs
1,500 – 5,000 $
a focused single-purpose app, one platform, no back end of your own.
5,000 – 10,000 $
a cross-platform app with accounts, content and a real back end.
10,000 – 20,000 $
a business app: roles, payments, offline behaviour, integration with your systems.
20,000 $ and above
a product: several apps or a platform with a mobile client, maintained over time.
Frequently asked questions
- iOS, Android, or both?
- Both, in almost every case, and cross-platform is what makes that affordable. If your users are overwhelmingly on one platform, we will say so and build for that one first.
- Do I need my own developer accounts?
- Yes, and we insist on it. Apple and Google accounts are opened in your name, and we work inside them. Your app, your accounts, your keys.
- Can the app work without a connection?
- Depending on what it does, yes. Offline support is a design decision made at the start, not a feature added later — tell us during the first call if your users lose signal, and we plan for it.
- How do updates get published?
- Through the same store accounts, with a review step each time. We can handle publication or hand you the procedure, whichever you prefer.
- Will it connect to my existing systems?
- Usually yes. If your CRM, ERP or back office exposes an API, the app can read and write to it. If it does not, we build the layer that lets it.
- What about the app store fees?
- Apple and Google each charge an annual developer fee and take a share of in-app purchases. Those are theirs, not ours — we will tell you exactly what applies to your case before you commit.
Thinking about an app? Book a free 30-minute call. We will tell you whether you need one, which platform to start with, and what it would take. No commitment.