Skip to content

Software, web & mobile

Apps that get past review and stay on the store.

For customers, or for the people doing the work in vans and warehouses. Built, submitted and maintained - because an app nobody updates quietly stops working.

Get a quote Ask a question

Building an app is the straightforward half. The half that catches people out is everything after: store review, the spread of devices it has to run on, two operating system updates a year that break something, and the fact that an app left unmaintained eventually gets pulled from the store entirely.

We build two quite different things. Customer-facing apps, where the competition is every other icon on the phone and the first thirty seconds decide everything. And field tools for your own team, where the user has no choice about using it, so the job is making it fast, obvious and reliable with one bar of signal.

And sometimes the honest answer is that you do not need an app. A good mobile website costs less, needs no download and cannot be rejected by a reviewer. We will say so if that is what we think, before you commission anything.

What drives the cost

Apps are quoted as a fixed price against a written scope. What moves it:

  • One platform or both, and whether cross-platform suits what it has to do.
  • Whether it must work offline, which changes the architecture rather than just adding a feature.
  • Hardware it has to touch - camera, scanners, Bluetooth, background location.
  • Whether there is already a backend and an API, or we are building that too.

The running cost is real and we quote it up front: developer accounts for both stores each year, plus maintenance to keep pace with operating system releases. An app is not a thing you buy once.

What you get

What an app project includes

iOS and Android together

One codebase where that suits the app, which most of the time it does. Two platforms without paying twice.

Native where it earns it

Camera work, background location, Bluetooth hardware and heavy offline use are sometimes worth building natively. We will tell you when they are and when they are not.

Offline that actually works

Field teams lose signal in basements, warehouses and half of rural Worcestershire. The app keeps working and syncs when it can, rather than showing a spinner.

The backend behind it

An app is a window onto something. We build the API and the admin side too, so it is one project rather than two suppliers.

Store submission

We handle the listings, the screenshots, the privacy declarations and the review process. First submissions get rejected for things nobody warns you about.

Crash reporting and analytics

You find out an update broke something from a dashboard, not from a one-star review.

Accounts in your name

Apple and Google developer accounts registered to you. The app is your asset - it should not be sat in an agency's account.

How it works

How an app project runs

No engineer turning up unannounced, and no invoice with surprises on it.

  1. 1

    Decide it is the right thing

    What the app does that a website could not, and who is opening it. If the answer is thin, we say so before anyone spends money.

  2. 2

    Design the screens

    Real screens with real content, on a real device, before anything is built. Cheaper to change now than later.

  3. 3

    Build in testable releases

    You get builds on your own phone through TestFlight and the Play console as it comes together. No six-week silences.

  4. 4

    Submit and support

    Through review and onto the stores, then a maintenance arrangement to keep it there.

Questions

The things people ask first.

A website is the right answer more often than the app industry admits. You need an app when it must work offline, use hardware like the camera or scanner, send push notifications people actually want, or be opened repeatedly by the same people. If somebody will use it once a year, a download is a barrier rather than a feature.

Usually both, built from one codebase, because the cost gap is small and choosing one halves your audience. Field tools are the exception - if you buy the phones, you only need to support the ones you bought.

You do. We set the developer accounts up in your name from the start. An app sitting in your agency's account is a hostage, and moving it later is painful.

Usually a few days once you know what the reviewers want, longer for a first submission. Rejections are normal and mostly about privacy declarations and metadata rather than the app itself. We deal with it.

Something breaks, roughly annually. That is what a maintenance arrangement is for - we test against the new version before your customers find it. An app with no maintenance has a shelf life of about two years.

Yes, and for field teams it usually has to. The app holds its own data and reconciles when a connection comes back. It needs designing in from the start rather than adding later.

Usually goes with

Most of this work comes as part of something bigger. Ask about any of it in one go and you get one scope, one price and one team.

Tell us what you need

A quick word about cookies

We use a couple of cookies to make the site work, and we count visits with our own analytics - no third parties, no advertising, and no IP addresses stored. You can turn the counting off and we will not record your visit at all. Cookie policy.