Build the experience that earns a place on the phone.

Not every digital product needs an app. A mobile app becomes worth building when the core experience genuinely benefits from frequent use, device capabilities, notifications, offline behaviour, or a repeat interaction that has to be faster than opening a browser. When none of those are true, a good responsive site usually reaches more people for less money.

A mobile app is designed around a moment, not around a feature list. Somebody is standing somewhere with one hand free and a job to finish, so each screen has to answer what to do next without being read carefully. Getting that right is most of what makes an app feel good, and it is decided long before anything is built.

A mobile app can use the camera, location, biometrics, files, background behaviour and notifications more deeply than a browser typically can. Each of those should be in a product because the job needs it, not because the platform allows it — every permission an app asks for is a moment where a user decides whether to trust it.

Parts of an app can be designed to work without a live connection when the workflow needs it. What can be done offline depends on what must be stored on the device, what can safely wait, and how conflicts are resolved when the connection returns — and the app should say which state it is in rather than showing a tick it has not earned.

Cross-platform means one application layer running on both iOS and Android with platform-specific adaptation where it matters, and it suits most business apps. Native means building separately for each platform, which earns its cost when a product depends on deep platform behaviour, sustained performance or hardware access. A web app or installable web experience is right when nothing about the product genuinely needs to be installed. Which one fits is decided from the behaviour, the platforms, the roadmap and what already exists.

Most apps need a backend, and many need some form of admin or operational interface: a team has to manage users, assign work, review what came in, handle exceptions and support people. How much admin a project needs depends entirely on what the business has to control behind the app — sometimes it is a handful of screens, sometimes it is most of the build.

We review the existing product and its APIs before deciding what can be kept. A web product often already has the accounts, data and services an app needs, and what is missing is the mobile workflow rather than the backend. An existing app is judged the same way: sometimes the interface is the problem, sometimes the dependencies are, and sometimes continuing it costs more than rebuilding around what it proved.

App-store submission is a release process, not an automatic approval. A build is prepared, tested on real devices, put in front of a small internal group, given the product information and privacy details the platforms require, and submitted for review — and review feedback is addressed if it comes. Where store submission is part of a project’s scope, we handle that; approval itself is the platform’s decision, and nobody can promise it.

Scope on an app build is mostly arithmetic: how many kinds of user, how many core journeys, whether both platforms are in scope from the start, how much backend and admin has to exist behind it, and how much of the hard behaviour — offline, sync, notifications, payments, device access — the product genuinely needs. What affects development time most is the number of distinct things to design, build, test on real devices and support.

LeanTrack Consumer health and fitnessmobile app UX/UI design · mobile app development

Headway Consumer EdTechmobile app experienceThe Body Coach Consumer HealthTechmobile app experience

Selected product work. Scope for each project is listed from its own record.

What is mobile app development?

Designing and building an application that people install on a phone — the experience itself, and the backend, admin and integrations behind it that make it useful once the phone is back in a pocket.

Do I need an app or a mobile website?

A mobile website is often enough when the experience is occasional, mainly reading or browsing, and reached by a link. An app starts to earn its place when people return often, when the phone’s own capabilities matter, when something has to reach them at the right moment, or when it has to keep working without a signal.

What is the difference between a mobile app and a web app?

A web app runs in the browser and needs no installation. A mobile app is installed on the device and can use camera, location, background behaviour, notifications and offline storage more deeply. Plenty of products end up with both, sharing the same backend.

Should we build for iOS, Android, or both?

It depends on where your users actually are, which is usually knowable from your existing traffic or customer base. Building both from the start is common with cross-platform, and choosing one first is a reasonable way to prove a product before doubling the surface to support.

Native or cross-platform?

Cross-platform suits most business apps: one application layer on both platforms, with platform-specific adaptation where it matters. Native earns its cost when a product depends on sustained performance, deep hardware access or platform-specific behaviour. The app’s behaviour decides, not fashion.

What do you build apps with?

Cross-platform apps in React Native and Flutter, with Expo where it suits the project, backed by Node or Python services and Postgres or Firebase depending on what the product needs. Which stack is right matters far less than whether the product decisions are.

Does an app need a backend?

Almost always. Anything with accounts, shared data, notifications, sync or an admin view needs a service behind it. An app that shows only what is on the device — a calculator, a converter — is the rare exception.

Does an app need an admin panel?

Usually some form of one. If a team has to assign work, review what came in, manage users, handle exceptions or support people, that has to live somewhere. How much admin depends on what the business needs to control behind the app.

Can a mobile app work offline?

Parts of it can, where the workflow needs it. What matters is deciding what must be stored on the device, what can safely wait to sync, and how conflicts are resolved when the connection returns — and being honest in the interface about which state the user is in.

Can an app use the camera, location and files?

Yes, where the product genuinely needs them. Permissions should be requested at the point the feature is used rather than all at once on first launch, and an app should only ask for what it actually does.

Can the app send push notifications?

Yes. The useful ones are tied to a real event, say enough to decide without opening the app, open directly on the thing they are about, and can be turned down by type. Notifications sent to raise engagement are the fastest way to get an app muted.

Can different users have different permissions?

Yes. Roles decide what each person can see and do — an operator seeing the work assigned to them, a manager assigning and reviewing it. Which roles exist is decided early because it shapes both the data and the screens.

Can the app connect to our existing CRM, software or API?

Where those systems allow it. We confirm what each one exposes — what can be read, what can be written, what it will not permit — and design around what is actually available rather than assuming an integration exists.

Can our existing web product become an app?

Often, and it is a good starting position: the accounts, data and services may already exist. We review the product and its APIs first, then keep what can serve a mobile client, adapt the workflows for a phone, and add what only mobile needs. Not every backend can simply be reused, which is why it is checked rather than assumed.

Can an existing app be redesigned or rebuilt?

Yes. We audit what is actually wrong as distinct from what is merely old, keep what works and what users already understand, and replace the parts holding the rest back. Sometimes the honest finding is that the app is fine and the problem is elsewhere.

Do all apps need a login?

No. An app showing the same thing to everyone may need no accounts at all. Once it holds something personal, assigns work to a specific person, or remembers anything across devices, it does.

Do all apps need payments?

No — most business and internal apps never take one. Where money does move in an app, what has to be defined is what is sold, how it is bought, what the purchase grants, and what happens on renewal or refund. Platform rules apply to what can be sold in an app and how, so that is checked against current policy for your specific case.

Can subscriptions be supported?

Yes, where the product needs them. Beyond the payment itself it means deciding what a plan includes, how access is granted and removed, what happens when a payment fails, and how it is handled on each platform — which is more product work than payment work.

Who handles App Store and Play Store submission?

We do, where store submission is part of the project scope: preparing the build, the listing information, and the privacy and permission details the platforms require, then addressing review feedback if it comes.

Is store approval guaranteed?

No, and nobody can guarantee it — approval is the platform’s decision. What can be done is preparing a submission that meets the published requirements and responding properly to review feedback, which is what we do.

Who owns the source code, accounts and data?

You do. Store and service accounts are set up in your name wherever the platforms allow it, so the listing and the users are never held by us. Handover includes the repository, the build configuration and the access it runs on, with documentation where that is in scope.

What determines mobile app development scope?

How many kinds of user, how many core journeys, whether both platforms are in scope, how much backend and admin has to exist, and how much of the hard behaviour — offline, sync, notifications, payments, device access — the product genuinely needs.

What makes one app project much larger than another?

Usually offline behaviour, the amount of admin behind the app, and the number of integrations. Those three change a build far more than the number of screens does.

What affects development time?

The number of distinct things to design, build, test on real devices and support, the state of any existing backend being reused, and how many product decisions are still open when the build starts.

What happens after launch?

Real use shows which parts of the app people actually open, where they stop, and what they contact you about. That decides what comes next — alongside the ongoing work of keeping up with OS versions, devices and third-party services.

What should we send before starting?

Who uses the app, what they need to do, where they are when they do it, what already exists, and which phone capabilities you think matter. That is enough to work out whether an app is the right answer and what a first version should contain.