02 · Mobile apps
Mobile apps, made useful
Thoughtful mobile experiences designed around the people who use them and the problems they need to solve.
Typical timeline: 4 weeks for a focused first release
Typical for a well-scoped first release, agreed in week one. Larger scopes are planned in phases.
What it is
A mobile app lives on your customers’ phones, works with patchy connections and has to pass the App Store and Google Play reviews. A useful one does a few things very well for the people who open it — and is backed by a reliable back end and the tools your team needs to support it.
Who it’s for
- Businesses whose customers need to act on the move: book, order, pay, check a status.
- Field teams that need a dependable tool away from a desk.
- Products where notifications, the camera or offline use genuinely matter.
Typical scope
A first release covers the core journey on both platforms, the back end it needs and publication in both stores. We set up versioning and the release process from the start, because every later update goes through the store reviews too.
How we work
How the project runs
01Week 01
Discover
Understand the business, clarify objectives, identify users and agree on scope.
You receiveA written scope and plan, agreed together.
02Week 02
Design
Shape the experience and settle what will be built before development begins.
You receiveDesigns you can click through, and the technical plan.
03Weeks 03–04
Build
Develop, test, refine and prepare the solution for launch.
You receiveTested software, live on accounts in your name.
04Ongoing
Run
Agreed maintenance, support and improvements after launch.
You receiveUpdates and improvements, or a documented handover.
Four weeks is our standard for a well-scoped project, agreed together in week one — not a promise for every project. Larger work is planned in phases, and ongoing support follows the engagement we agree.
Quality, shown
The technical standard
What every project includes, whichever service you choose.
See how this site measures up| Commitment | Standard |
|---|---|
| Code review | Code review on every change before it’s merged |
| Automated tests | Unit and end-to-end tests, with a DevSecOps pipeline, scope agreed per project |
| Accessibility | Designed and tested against WCAG 2.2 AA |
| Performance | Performance budgets targeting “good” Core Web Vitals, tested on mid-range Android |
| Security | Security review based on the OWASP Top 10 before launch |
| Updates | A written update every week |
| Ownership | Repository and accounts set up in your name; you own the code as set out in your contract |
| Handover | Documentation, architecture notes and a handover walkthrough (recorded on request) |
Mobile apps
Frequently asked questions
Do we need separate apps for iOS and Android?
Usually not. For most business apps one cross-platform codebase gives both, with less to maintain. When an app needs deep access to one platform, we say so during Discover and plan for it.
Can a useful app really ship in four weeks?
A focused one can — one core journey done well, published in both stores. We agree the scope in week one. Larger apps are planned in phases, each with its own release.
Who publishes the app in the stores?
The developer accounts are created in your name, and we handle submissions and store reviews with you. The app stays yours if we stop working together.
What happens when Apple or Google update their systems?
Both stores raise their requirements every year. Under an agreed support plan we keep the app compatible; otherwise the documentation explains exactly what to update.