Case still
Case study
—
—
—Before
—After
Our people need it on their phone, offline, and a website cannot do that.
01What it involves
Six stages, starting with what it is actually for.
Apps that disappoint were usually asked to do everything at once. So we start with the one job it must do better than a website, for the people who will hold the phone. The rest waits for version two.
Point at a stage, or tap it, to play it.
-
01
Discovery and scope, version one only
A working session with the people who will use the app, not just those who asked. It ends with one job, the phones it must run on, what must work offline, and the scope and price agreed. After that, every change is logged, priced if needed, and approved.
Stage clip · not made yet -
02
Flows and prototype, before any code
A clickable prototype on a real phone. It is cheaper to learn in week two that the field team holds the phone in one hand than in month three.
Stage clip · not made yet -
03
Interface design, for phones, not monitors
Made for thumbs, glare and gloves: large targets, short forms, and a clear answer for when the signal drops mid-task.
Stage clip · not made yet -
04
Build, offline from the start
One codebase for iPhone and Android, unless the job needs what only native code does well. Offline storage and sync are built in, not bolted on, and test builds reach your own phone as it goes.
Stage clip · not made yet -
05
Testing and release, store review handled
Tested on the older, cheaper phones your team actually carries, not just the newest, then taken through App Store and Google Play review in your company’s name. Answering a rejection is our job.
Stage clip · not made yet -
06
Handover, and nothing held back
The code, store listings and signing keys stay in your name. Leave us and you keep the app, with the documentation another team needs to carry it on.
Stage clip · not made yet -
From you
What we need from you (it is a short list)
- One decision-maker who can sign off
- Two or three of the people who will use it, for an hour at each stage
- Apple and Google developer accounts in your company’s name
02Proof
Three apps where a website would not do.
Not a highlight reel. Three jobs done away from a desk, each with how many of the team still open the app every week.
Case still
Case study
—
—
—Before
—After
Case still
Case study
—
—
—Before
—After
On camera
Hear it from someone who paid us.
Quote pending — an App Development client, in their own words, on what changed.
Client nameRole, Company
03Questions
Five questions that only come with an app.
Cost, timeline, team and scope live on the services page. These are the ones a phone adds.
Often it would, and we will say so on the first call. An app earns its cost when the work is on a phone away from a desk, must run offline, or uses the camera, location or notifications daily. Otherwise, a fast mobile site is cheaper to build and easier to keep.
Usually both, from one codebase: one build, two versions in step. We suggest separate builds only when the job needs something a shared codebase does badly, and we name it before you pay for it.
It keeps working. Offline entries wait on the phone and send once the signal returns, and the user can always see what has gone through and what has not. Which tasks work offline is settled in stage one, because it shapes the rest.
You do. It is published under your company’s developer accounts, the repository is in your name, and the signing keys are handed over at the end. Nothing is held back to tie you to us.
Phones and app stores change every year, and an untended app breaks sooner than most expect. Our Websites & Apps AMC plan covers updates, new store rules and fixes, or your own team gets everything, documentation included.
05Start here
Tell us the one job it has to do.
Thirty minutes, no deck. Bring the task your team does on the move, and how they do it now. You leave with a straight answer: app, mobile site, or neither.