Automation

Business app development for iOS and Android

Your people work away from a desk: on site, in the van, in the warehouse. What happens there goes onto paper or into a message, and in the evening someone types it into the system. You are thinking about an app. What you do not know is whether it should be an app, what that costs, and what you are tied into afterwards.

I design and build apps for business use: for your own staff, or for a defined group of customers or members. Not a consumer app that lives or dies by downloads and ratings; that distinction changes almost every decision along the way. The app does not have to win in a store, it has to work reliably on the handsets your people are already carrying. So the conversation starts not with the design, but with whether this needs to be an app at all.

When an app is the right answer

An app earns its keep where the phone can do something a browser cannot. These situations qualify.

Your field staff record work on site: photos, meter readings, a signature for sign-off, including at addresses with no coverage.
You want to scan barcodes or QR codes with a phone camera instead of with separate scanners.
A notification has to appear the moment something happens, not when someone next opens a tab.
A defined group of customers or members needs access to their own data: orders, status, documents, behind a login.
Your people work in gloves, in the cold or in the dark, and a web form on a small screen does not survive that.
A web application already exists, but its mobile side is a compromise nobody uses.

What the work covers

From the first assessment to an app that sits in the store and can carry on without me.

The prior question: app or mobile web application. Both routes costed before a line of code is written.
Native or cross-platform as a cost decision, not an article of faith. One codebase for iOS and Android saves on build and on maintenance; native pays off when the app has to reach deep into the device.
The offline design: what is stored locally, when it synchronises, and what happens when two people have changed the same record. That last part is the real work.
Integrations with the systems you already run, so the app does not become a second set of books.
Publication in the App Store and Google Play, including what review demands: a privacy statement, a declaration of what data you collect, and a test account that gets the reviewer past the login.
Distribution without a store, when the app never needs to leave the company: rollout through the mobile device management platform you use.
Maintenance as a standing budget line. New OS versions, expiring certificates and shifting store policy force updates, even when nothing in the app itself changes.

What you keep

An app is only delivered once you can publish it without me. That means the accounts, the keys and the code are yours.

The app, published in both stores or rolled out through your own management platform.
The source code in a repository owned by your organisation, with the full history.
The developer accounts and signing certificates in your name. Lose those and you can no longer ship an update, which is exactly why they do not belong with a supplier.
A release procedure of a few pages: build, test, submit, and the traps along the way.
A handover to your own developer or to a party of your choosing.

What it is not

Not a consumer app. An app that depends on downloads, ratings and discoverability needs marketing I do not provide.
Not an app because an app looks modern. If a mobile-friendly web application will do, I will say so, even where that means a smaller engagement for me.
Not a builder who keeps the keys. I do not deliver an arrangement that sends you back to me for every change.
Not a design agency. You get a clean, consistent interface; a brand identity with the imagery to match is work for a designer.
No games, no AR, and no apps whose entire reason to exist lies in the store itself.

Common questions

Do I genuinely need an app, or will a website do?

That depends on whether you need something a browser cannot give you. A modern mobile browser handles camera, location and file upload, and a web application spares you stores, review rounds and installation on devices. An app earns its keep on four things: working a full day without a connection, push notifications that arrive even when the app is closed, tasks that continue in the background, and links to peripherals over bluetooth. If your question is not on that list, an app is a more expensive way to do the same thing.

Native or cross-platform: which is sensible?

Native means building twice and maintaining twice. Cross-platform means one codebase for both, with a thin layer per platform where that is genuinely needed. For a business app with forms, lists, camera and synchronisation, the difference in user experience is small and the difference in cost is large. Native only becomes worth considering with heavy graphics, intensive sensor use, or an integration that exists on one platform only.

What do I have to arrange myself for the App Store and Google Play?

A developer account per store, in your organisation's name, for which the platform owner charges a periodic fee. Both require a D-U-N-S number for a business account; obtaining one takes a few working days and runs on your own company details. Beyond that: a published privacy statement, a completed declaration of what data the app collects, and a test account for the reviewer. I guide the application, but the accounts stay yours. Allow a few days of review per submission, and allow for the possibility that a submission is rejected on a formality.

Will the app work without internet?

If you set that requirement up front, yes. Offline is not a switch that gets flipped afterwards: it determines how data is held locally and how conflicts are resolved once the device reconnects. It is the requirement that costs the most, and at the same time the one that makes the difference for people working in a basement, a shed or the countryside. What cannot go offline is anything needing a current answer from another system.

Can the app stay inside my organisation?

Yes. An app intended only for your own staff does not have to sit publicly in a store. Both platforms offer a route for private distribution, where you push the app to company handsets through your management platform. That saves a public listing and part of the review burden. If you have no mobile device management platform yet, that is a choice we make first: rolling apps out onto devices you do not manage is a problem that surfaces later.

What does it cost?

Three things drive the size: the number of screens where someone actually does something, whether offline working is required, and how many existing systems hang off it. I work on a time-and-materials basis with an agreed ceiling, or at a fixed price for a defined result when the question is sharp enough to allow it. I name the figure in the first conversation, together with the shape that fits your question. Budget separately for maintenance: the platforms change every year, even when your app does not.

More within this service

Not sure it needs to be an app?

An introductory conversation is without obligation. Sketch what your people need to be able to do out in the field; I will say honestly whether that calls for an app.

Book an intro call Send a message