Native apps (iOS and Android)
Two separate apps, each written for its own system. Top performance and full access to the phone. They cost more and take longer, because the work is done twice.
Services · 06
Mobile app development for companies
An app makes sense when people use it often, or when you need something a browser cannot do: notifications, the camera, working without a connection. In every other case a website or a web app costs less and is enough. We start from that question, before choosing how to build it.
When you really need an app
The first step is to work out whether an app is the right answer. Often it is, but not always.
- Frequent usePeople open the app every day or every week: staff in the field, regular customers, subscribers. An app earns its place on the screen only through repeated use.
- Phone featuresNotifications, the camera, location, code scanning, biometric sign-in. When you truly need them, an app can do more than the browser.
- Working offlineWarehouse, building site, inspections: where the connection is weak, data is saved on the phone and synchronised later.
- Presence on the storesIn some sectors being on the App Store and Google Play is part of credibility. On its own, though, it is not enough of a reason to build an app.
When something else is enough. If people only need to read content, book or fill in a form, a fast website or an installable web app is often enough, with one codebase and no store. We say so before quoting: if the right solution is smaller, we write that down.
Native, cross-platform or web app
Three routes, with different costs, timing and limits. The choice is made after the analysis, not before.
Cross-platform apps
One codebase for iOS and Android. Costs and timing are usually lower, and it suits most business apps. A few very specific features may need native parts.
Installable web app (PWA)
A web application added to the phone screen. No store, instant updates, one codebase. The features available depend on the system, and on iPhone they are more limited.
What an app project includes
Five parts, always in the same order. Skipping one is the most common way to end up with an app nobody uses.
Features and priorities
We define what the first version must do and what can wait. A small first version that people really use teaches more than a big one that never ships.
Experience design
Screens and flows designed for one-handed use, on the move, with little time. A prototype to try before any code is written.
Development and connections
The app and, when needed, the server side: data storage, sign-in, links with your management software, payments and external services through APIs.
Testing on real devices
Tests on different phones and system versions, with real cases, before delivery.
Publishing and updates
Preparing and submitting to the stores, answering the Apple and Google reviews, and updates after release.
How it works
In successive releases: each phase has a clear purpose and prepares the next.
Analysis
A call to understand goals, users and constraints, then a written scope with features, platforms and success criteria.
Prototype
Clickable screens to try with the people who will use the app. Corrections here are cheap; later they cost far more.
Releases
Intermediate versions to try every few weeks, so you see what works before the end.
Testing and publishing
Tests on real devices, then submission to the stores and handling of the reviews.
After release
Updates for new operating systems, fixes and new features based on real use.
What we do not decide
Three things worth knowing before you start.
Publishing depends on Apple and Google. Their reviews follow rules and timing we do not control, and an app can be rejected and need changes before it is approved.
Developer accounts have their own costs. Apple and Google charge a fee to whoever publishes, paid by the company. The account should be in the company name, so that the app stays yours.
An app has to be maintained. New versions of the operating systems come out every year, and an app that is not updated sooner or later stops working well. Maintenance is agreed before release.
Frequently asked questions
An app or a website?
It depends on how it is used. For occasional reading and buying, a fast website or a web app is enough and costs less. An app is needed when use is frequent, phone features matter or the work must run without a connection. It is decided in the analysis.
How much does an app cost?
It depends on how many features it has, how many platforms it covers and how much it connects to other systems. We do not publish a price list: after the analysis you receive a written quote with scope, timing and costs.
Do you also build the server side?
Almost every app needs a server side for data, sign-in and notifications. We build it together with the app, or connect it to your existing management software through APIs.
Who publishes the app on the stores?
The developer account should be in the company name, so the app stays yours. We can handle the preparation and submission, but the final decision belongs to Apple and Google.
Can the app connect to our management software?
Yes, if that software offers a way to exchange data (an API or files). If it does not, we look at alternatives before settling for compromises.
Close to this service
Custom software
Management tools, client portals and dashboards built on your process. Often the server side of the app.
AI automation
Fewer manual steps and assistants that answer customers, including inside an app.
Website design
When a fast, well-made website is enough, with no store involved.
Industries
What changes when the work serves a craft business, a restaurant or a practice.
What should the app do every day?
Tell us who will use it and what they must be able to do. We will tell you whether you need an app, a web app or something smaller.