Mobile app development, from idea to release

The hard part of an app is rarely building it. It is working out which version is worth building.

The problem

What usually goes wrong

Apps fail in a predictable way. The scope is set by everything the idea could eventually become, the budget is spent reaching that first release, and it launches to an audience who have not yet been given a reason to install anything. By the time real feedback arrives there is nothing left to respond with. The cause is almost never engineering.

How we think about it

Our approach to mobile app development

The single most useful conversation in an app project happens before any design work, and it is about subtraction.

An idea usually arrives fully formed and fairly large. The job is to find the one thing inside it that a real person would open twice, and to build that. Not because ambition is a problem, but because the first release is the only honest information you will ever get about whether the thinking was right, and you want to reach it with budget still in hand.

That means saying no to a lot of reasonable ideas, temporarily. Login, settings, profiles, notifications, an admin panel — each is defensible, and together they consume the budget before anyone has used the thing that made the idea worth having.

After release the priorities are almost always different from the plan. That is not a failure of planning; it is the point. Real usage tells you which of the deferred features mattered, and by then you are building against evidence rather than against a wish list written before anyone had touched it.

Capabilities

What this covers

What gets delivered. What it is built with is a decision made per project, against what your business already runs and what your team can maintain.

Concept definition and scoping
MVP design and build
iOS and Android applications
Customer-facing applications
Internal and field applications
Offline-capable workflows
Integration with your existing systems
App store submission and release
Ongoing maintenance and iteration

How it works

The way we run this work

01

Test whether it needs to be an app at all

Push notifications, offline use, the camera, location, or something people open several times a day — those justify an app. If none apply, a well-built mobile web experience usually reaches more people for less money, and we will say so.
02

Cut to the smallest version someone would use

Not the smallest version that demonstrates the idea. The smallest version a real person would choose to open a second time. That is a much sharper test and it removes a great deal of scope.
03

Build for the field, not the boardroom

Apps used for work are used one-handed, outdoors, in poor light, with gloves on and no signal. That reality should shape the interface long before the visual design does.
04

Plan the release, not just the build

Store submission, device testing, staged rollout, crash reporting and a way to ship a fix quickly. An app you cannot update safely is a liability.

Use cases

When businesses come to us about this

Recognisable situations rather than client names. If one of these describes your week, it is worth a conversation.

A field team on paper

Job sheets, inspections, checklists or timesheets filled in on site and rekeyed into a system afterwards, with the double handling introducing every error.

A customer-facing product idea

A business has a genuine idea and needs to know whether it works before committing to the full version of it.

A companion to an existing system

The desktop system is fine; what is missing is the part that has to happen away from a desk.

Work that continues without signal

Remote sites, basements, regional roads. Data captured offline and synchronised when a connection returns, without anyone thinking about it.

Questions

Common questions

iOS, Android, or both?

It depends on who uses it. For an internal or field app, it is often decided by the devices the team already carries, and building for one is materially cheaper. For a consumer product, both is usually the expectation.

How much does an app cost?

Honestly, the range is too wide for a number to mean anything before scope. What we can do quickly is a scoping exercise that produces a fixed price for a defined first release, so you decide with a real figure rather than a guess.

What happens after it launches?

Operating systems update, devices change, and store requirements shift. An app needs periodic maintenance whether or not you add features, and that should be budgeted for from the start rather than discovered.

Can it work with our existing systems?

Usually, and it should — an app that holds its own separate copy of the data creates more problems than it solves. What is possible depends on what your current systems expose, which is one of the first things we look at.

Start a project

Talk to us about mobile app development

Tell us what you are trying to solve. A few sentences is enough — we will ask the rest.