Four Build Scenarios, Written Out in Full
How we scope a real app: the situation, the constraint that only exists because it is a phone, what goes into version one, and the things we argue should wait.
Read This First: These Are Not Case Studies
Our client work is under NDA. We do not publish client names, app names, logos, screenshots, store links, download counts, ratings or quotes attributed to anyone, and we are not going to start by inventing them.
What follows are representative build scenarios: composite descriptions of the kinds of app we scope, written to show how the decisions get made. The situations are typical rather than specific. Every figure — weeks, screen counts, sprint numbers — is an illustration to make the shape of a project legible, and each is labelled as such where it appears.
If a studio shows you glossy case studies with impressive numbers and no way to verify any of them, ask which parts you are allowed to check. The honest answer for most agency portfolios is uncomfortable. We would rather show you the reasoning and let you test it on a call about your own project.
A Field-Service App for Engineers Working Out of Vans
The most common internal-app shape we are asked about, and the one where the mobile constraint dominates every other decision.
The situation
A maintenance business runs a couple of dozen engineers from vans. Jobs are dispatched by phone call and text, paperwork comes back on carbon-copy pads, and photographs of completed work live on personal handsets. Invoicing lags the work by several days because somebody in the office has to type it all in, and disputes about what was done are impossible to settle.
The job management system in the office already holds the scheduling and the customer records. It has an API. Nobody has ever put it in an engineer’s hand.
The mobile constraint
Engineers work in plant rooms, basements, lift shafts and rural sites. There is no signal, and there is no point pretending otherwise: the app has to be fully usable with the network off. Not a cached read-only view — an engineer must complete forms, take a dozen photos and capture a signature with nothing connected.
That makes the sync engine the centre of the project, not the screens. A local database, an outbound queue that survives the app being killed, photo uploads that resume rather than restart, and a settled rule for what happens when the office edited a job while the engineer was underground.
In version one
The full day, offline, end to end
- Today and tomorrow’s jobs downloaded automatically each morning
- Site history and previous reports available with no connection
- Job forms, parts used, photos before and after, and a signature
- A visible sync status, so nobody has to guess whether work was sent
- Android only, because the company issues the handsets
Deliberately deferred
Wanted, and worth waiting for
- Live van tracking, which is a battery and privacy conversation of its own
- Van stock and parts reconciliation, a whole inventory problem in disguise
- A customer-facing app showing appointment windows
- An iOS build, until somebody actually carries an iPhone for work
- In-app invoicing, once the office trusts the data coming back
Weeks 1–3 — design and the offline model
Flows, screens, prototype, and the sync rules agreed in writing before anything is built.
Weeks 4–13 — build in five sprints
Sprint one is local storage and the sync queue. Photos and signatures land in sprint three, on real handsets.
Weeks 14–16 — device QA and a pilot
Two engineers run real jobs on it for a fortnight while the paper pads stay in the van as a fallback.
Weeks 17–18 — rollout
Internal distribution to the fleet, then a support plan covering OS updates and the job system changing underneath.
Illustrative timeline for a scenario of this shape. It is not a schedule from a client project, and your own numbers would come from a scoping call.
A Loyalty and Ordering App for a Multi-Site Food Business
Consumer-facing, both stores, and a project where the till system quietly decides what is possible.
The situation
A food business with a handful of sites runs a paper stamp card and takes collection orders over the phone at lunchtime, which ties up a member of staff during the busiest hour. They want ordering ahead, a loyalty balance people can see, and the ability to send an offer at eleven in the morning rather than hoping customers remember them.
Each site has slightly different opening hours, a slightly different menu and its own stock problems. There is a point-of-sale system across all of them.
The mobile constraint
The customer is standing in a queue or walking, using one hand, on venue wifi that barely works. Every step of the order flow has to be reachable with a thumb in the lower half of the screen, and the whole path from opening the app to paying has to survive a connection that drops halfway.
Payment is the sharp edge: a dropped request must never leave someone unsure whether they have been charged. That means idempotent order submission and a status screen that tells the truth, rather than a spinner and hope.
In version one
Order, pay, collect, earn
- Site picker, per-site menu and opening hours
- Order ahead for collection, with a card saved for next time
- Loyalty balance on the first screen, with a scannable code
- Push notifications with a genuine reason to allow them
- Both stores from one shared codebase, plus a simple admin view
Deliberately deferred
The second release, on purpose
- Delivery, which means drivers, dispatch and a completely different operation
- Table ordering with QR codes at each table
- Tiered loyalty and referral mechanics before anyone has used the basic one
- Live order status pushed from the kitchen screen
- Guest checkout without an account, revisited once the data says it matters
Weeks 1–3 — design and the till integration check
Screens and prototype, alongside proving early that orders can actually reach the kitchen.
Weeks 4–15 — build in six sprints
Menu and ordering first, payments in the middle with real cards in a sandbox, loyalty last.
Weeks 16–18 — QA, one pilot site, store listings
A single site runs it live at lunchtime while the listings and screenshots are prepared.
Weeks 19–20 — submission and launch
Both stores, staged rollout on Android, with room in the plan for a first-submission rejection.
Illustrative timeline only. Weeks, sprint counts and site numbers are a worked example, not results from a client engagement.
A Booking App for a Clinic Group
Deceptively simple on the surface, and almost entirely about the rules nobody mentions on the first call.
The situation
A group of clinics takes appointments by phone and through a web page that patients describe as fiddly. Reception spends a large part of the day rescheduling, and missed appointments are a real cost. They want patients to book, reschedule and cancel from a phone, and to receive reminders that actually land.
The practice management system is the source of truth for availability and must stay that way. Nobody is replacing it, and nobody is allowed to double-book a room.
The mobile constraint
Patients skew older and the handsets skew older with them. The app has to be legible at the largest accessibility text size without the layout collapsing, and it has to work on phones several years old without a modern processor to hide any sloppiness.
Health information also changes the rules: less is cached on the device, sensitive screens are hidden from the app switcher, biometric unlock is offered with a proper fallback, and the store privacy declarations have to match exactly what the app collects. Push notifications carry a reminder, never a diagnosis.
In version one
Book, move, cancel, be reminded
- Live availability read from the practice system, never a second calendar
- Book, reschedule and cancel within the clinic’s own rules
- Reminders at intervals reception can configure themselves
- Biometric sign-in, short sessions and account deletion in the app
- Both stores, tested against the largest text size and an old handset
Deliberately deferred
Everything that needs clinical sign-off
- Video consultations, which is a product rather than a feature
- Test results and clinical records in the app
- Messaging between patient and practitioner, which needs a duty-of-care policy first
- Taking payment in the app, until the refund process is agreed
- Family accounts booking on behalf of someone else
Weeks 1–4 — design, rules and accessibility
Booking rules written down properly, and the prototype tested at the largest text size before sign-off.
Weeks 5–14 — build in five sprints
The availability integration first, because everything else depends on it behaving.
Weeks 15–17 — QA, privacy review and old devices
Data handling reviewed against what the declarations say, on the handsets patients actually carry.
Weeks 18–19 — submission and a single-clinic launch
One site goes live first so reception can learn the app before the whole group does.
Illustrative timeline. Health-related apps attract extra store scrutiny, so real schedules leave more room around submission than a worked example can show.
A Rescue: the Original Developer Stopped Replying
The most common enquiry we get after a build has gone wrong somewhere else, and the one that starts with an audit rather than a plan.
The situation
An app is roughly eighty per cent finished, or so the last invoice said. The developer has gone quiet. Nobody internally can build the project. The repository may or may not contain everything. The signing key might be on somebody’s laptop, and the store accounts were opened under the developer’s name rather than the company’s, which is the single most expensive mistake on this page.
The owner has been told by one firm that it can be finished in a fortnight and by another that it needs a total rewrite, and has no way to judge either claim.
The mobile constraint
Mobile makes an abandoned project worse than an abandoned website. A website can be redeployed; an app cannot be updated at all without the original signing key or the account that owns it. Recovering that can take weeks of account-transfer requests and paperwork, and on one platform a lost upload key has to be replaced through a support process rather than by decision.
So the first questions are not about code. They are about who owns the accounts, who holds the keys, and whether the app can be built and signed at all.
Week one: the audit
Before anybody promises a date
- Can the project be built from source, on a clean machine, with no help?
- Who holds the store accounts, the certificates and the upload key?
- How much of the eighty per cent is real, tested on a handset?
- Which dependencies are unmaintained or pinned to an old platform version?
- Are there keys or credentials sitting in the app bundle?
The verdict
Continue, or start again
- Continue when the architecture is sound and the gaps are features, not foundations
- Rebuild when fixing costs more than replacing, which is more often than anyone wants to hear
- Sometimes keep the backend and rebuild only the app, or the reverse
- Occasionally the honest answer is that the original developer should finish it
- Either way the report is yours, with a costed plan for both routes
Weeks 1–2 — audit and access recovery
Build it, read it, run it on a handset, and start any account transfer immediately because it is the long pole.
Week 3 — written verdict and two costed routes
Continue or rebuild, each with a range and the assumptions underneath it. Yours to take anywhere.
Weeks 4–12 — the chosen route
In a continue, the first sprint is always the release pipeline: getting a signed build out before touching features.
Then — a support plan
Because the reason this app stalled was that nobody was responsible for it once the build money ran out.
Illustrative timeline. Account and key recovery depends on the platforms and on the previous developer, so this is the scenario where a real schedule varies most.
Four Different Apps, the Same Four Decisions
The network is not assumed
Each scenario states plainly what the app does with no signal, and that answer is settled during design rather than discovered in QA.
The integration goes first
The system we do not control is proved in the first sprints, never the last, because that is where the unpleasant surprises live.
Something good gets cut
Every version one leaves out features the client wanted. That is the discipline that gets an app launched instead of perpetually nearly finished.
Launch is not the end
Each one finishes on a support plan, because an app with nobody responsible for it is the scenario that becomes the fourth story.
These scenarios are composites written to illustrate method. They do not describe any particular client, and no figure on this page is a client result.
Get a Scenario Written for Your Own App
Tell us what you want built and we will come back within two business days with the same thing in writing: the constraint, a scoped version one, what we would defer and why, and a cost range.