Mobile App Consulting
Three weeks, a fixed price, and a document that says what we would do and why. Including, quite often, that a mobile app is not the answer.
- Duration
- Three weeks
- Team shape
- One senior engineer, one architect
- Ends with
- A written recommendation
The most expensive mobile decision is made before anyone writes code
Native or shared, one platform or two, app or mobile web — these get decided early, usually on incomplete information, and they set the cost of everything afterwards. Reversing one two years in is a rebuild.
This is a fixed-scope engagement with a fixed price and a written output. We look at who uses the product and where, what the devices and connections are actually like, and what the app would have to reach on the device to be worth being an app. Then we come back with a recommendation and the reasoning. You own the document, there is no obligation to build with us, and a recommendation against an app is a legitimate result.
What usually goes wrong, and what we do instead
The failure mode is not bad analysis. It is a platform decision made as a preference.
Where mobile scoping goes wrong
- Native or cross-platform chosen by team preference rather than by need
- An app specified without anyone watching the work it is meant to support
- Device and connection assumptions taken from the office, not the field
- Store, MDM and distribution constraints found after the build
- A recommendation that could never have been 'do not build an app'
How we run it instead
- The platform decision derived from what the app has to reach on the device
- Time spent where the product will actually be used
- The real device and connection profile, measured rather than assumed
- IT, security and distribution constraints established in week one
- A recommendation that can be mobile web, or nothing, and sometimes is
What the three weeks cover
The same ground every time, because the gaps are usually in the parts nobody thought to mention.
01
The people and the place
Who uses this and where, observed rather than described. Field work looks different from how the office remembers it.
02
The device estate
What hardware and OS versions your users actually carry, and what connection they have where they work.
03
What must reach the device
Camera, location, Bluetooth, background work, offline storage. This is what decides native versus shared.
04
The data picture
What syncs, how often, and what happens when two people change the same thing offline.
05
Distribution and policy
Store rules, device management, identity and whatever your security team requires before deployment.
06
The options
Native, shared codebase, progressive web app or mobile web — costed against each other over three years.
How we reach a recommendation
Four questions, asked in order. A no at any of them changes the answer, and we say so rather than continuing to the next.
Does this need to be an app at all?
An app is a distribution and update cost you carry forever. It should be earning that.
- What the app would reach on the device that a browser cannot
- Whether the usage pattern justifies an install
- Whether a progressive web app would do the same job
Native, or a shared codebase?
This is the decision with the longest tail, and it should follow from capability rather than preference.
- What has to reach the hardware, and how deeply
- How much of the interface must feel platform-native
- Who will maintain it, and what they can already hire for
Can it be deployed?
A built app that IT will not distribute is a sunk cost, and this is found late more often than it should be.
- Store or managed distribution, and what each requires
- Identity, device management and the security position
- What the release path looks like when something is wrong
What is the smallest first step?
Any recommendation that starts with a twelve-month programme is one we have not thought hard enough about.
- The one workflow that would prove or disprove the approach
- What it would cost and how long it would take
- What we would learn that would change the rest of the plan
What you end up with
Stated from your side rather than ours.
A document you can act on
Precise enough to build from, tender from, or take to a board, and written to be read by people who were not in the room.
A platform decision with reasoning attached
Native or shared, decided from what the app has to reach on the device rather than from what your team would enjoy building.
Options with their costs attached
App, shared codebase, PWA and mobile web compared over three years, so the decision is a choice rather than a default.
A defensible first step
The smallest piece of work that would tell you whether the rest is right, sized and costed.
How the three weeks run
The same five stages as every engagement, compressed into a fixed scope.
Diagnose
Week one: the people, the places, the devices and the constraints. Mostly watching, and measuring.
Decide
Week two: options developed and costed, and the trade-offs made explicit.
Prove
Where a device capability decides the answer, we build the smallest thing that tests it on real hardware rather than reasoning about it.
Deliver
Week three: the recommendation written, then walked through with the people who have to act on it.
Hand over
The document is yours, including if you take it to somebody else to build.
What you get, and when
One document, and the working material behind it.
- The real device and connection profile, measured
- What the app must reach on the device, and how deeply
- Distribution, identity and policy constraints we found
- Native, shared, PWA and mobile web costed against each other
- What each option gives up, stated plainly
- The risks that would change the answer
- One recommendation, with the reasoning that produced it
- A sized and costed first workflow
- A walkthrough with your team, and the document to keep
Where it can lead
Three of the seven ways we work. Which one follows a diagnostic depends on what the diagnostic found, and none of them is the default.
Discovery / Assessment
A time-boxed investigation that ends in a written recommendation, including the recommendation not to build. You can act on it with us or without us.
Best when the problem is agreed and the solution is not.
- Where it fits: a business case nobody can evidence, or a system everyone blames.
- A written problem statement, the options considered, and the reasoning for each.
- You own the decision at the end; we own the evidence behind it.
Consulting / Advisory
Senior engineering judgment applied to decisions you are already making — architecture, vendor choice, a rebuild someone has proposed. No delivery attached.
Best when you have the team but not the second opinion.
- Where it fits: an in-house team facing a decision it cannot take twice.
- Architecture review, technology selection, or a rebuild proposal tested before it is funded.
- You own the decision and the delivery; we own being right about what we told you.
Fixed-Scope Delivery
A defined piece of work, scoped and priced up front, delivered end to end. Scope changes are re-priced in the open rather than absorbed quietly.
Best when the scope is stable enough to write down and hold.
- Where it fits: a replacement, an integration, or a first release with firm edges.
- Fixed budget, so the risk of a wrong estimate is ours, not yours.
- We own scope, estimate and delivery risk; you own acceptance.
The rest of our mobile work
A mobile engagement rarely stops at one of these. These are the ones next to it.
Related work
Engagements where the platform decision mattered as much as the delivery.
Questions about the diagnostic
The ones we are asked most often before a first conversation.
What does it cost?
Do you actually recommend against building an app?
We already have an app. Is this still useful?
Do we own the document?
Why do you need to visit where our staff work?
Are we committed to building with you afterwards?
Not sure whether you need an app?
Tell us what you are trying to decide. Three weeks is usually enough to answer it properly.