Mobile app development

We build mobile applications — and, more often than clients expect, we tell them they do not need one.

That is not modesty. Apps earn their cost through repeat usage. An icon on someone's home screen is valuable when they open it weekly and worthless when they use the service twice a year. A great many businesses that commission an app end up with something that duplicates their website, costs several times more to maintain, and is installed by very few people.

So the first conversation is about whether the project is an app at all.

Deciding what you need

A responsive website is enough when usage is occasional and nothing needs hardware or offline operation.

A progressive web app covers most content, transaction, and form-based products — stores, booking systems, portals, dashboards. Installable to the home screen, works offline, no app store required, updates ship instantly.

A native app is genuinely required when you need deep hardware access — Bluetooth peripherals, NFC, background location, biometric authentication, advanced camera control — heavy graphics, reliable background operation, or app store distribution as an acquisition channel.

We wrote the full decision framework, including the iOS caveat that decides more projects than anything else: native app or PWA.

What we build

Native iOS and Android, where platform capability requires it.

Cross-platform, where one codebase serving both stores is the sensible trade-off.

Progressive web apps, where store distribution is not the acquisition channel.

Backend and API work to support any of the above.

How we work

1. Scoping. What the app has to do, which specific hardware capabilities it needs, and how often a typical user will engage. If the first two produce no concrete answers, we say so.

2. Architecture. Platform decision, technology stack, integration points, and data model — documented before build rather than emerging during it.

3. Design. Interface design following each platform's conventions rather than forcing one design onto both. Users expect an iOS app to behave like an iOS app.

4. Build. Iterative, with working builds you can install and use rather than screenshots.

5. Store submission. App Store and Google Play listings, review process, and the assets each requires.

6. Handover. Source code, repository access, store accounts under your control, and documentation.

What you receive

• Full source code, repository access transferred to you
• App Store and Google Play accounts in your name
• Backend infrastructure under your control
• Design source files
• API documentation
• Technical documentation for a future developer
• Written transfer of ownership on final payment

Store accounts registered in your own name matter. Accounts held by a development agency become an obstacle at exactly the moment you want to change supplier.

What we will tell you honestly

If your usage pattern does not support an app, we will say so and propose the website instead — even though it is a smaller project.

If a required capability is unavailable on iOS through a progressive web app, we will tell you before you commit to that route rather than three months in.

If a competitor's app is the reason for the project, we will ask what evidence exists that their users open it.

Recent work

---