The build is the cheap part. Everything after it is not.
Anyone can ship a first version. What determines whether an application is still useful in three years is what gets decided in the first three weeks — budgets, ownership, and who maintains it.
We agree the limits before we write code.
Performance and accessibility are not features you add at the end — by then the architecture has already decided them. So we set numeric budgets during scoping and treat breaching one as a build failure, the same as a broken test.
It is an unusual conversation to have in week one. It is also the reason our applications do not need a rescue project in year two.
A budget you cannot fail is a preference. We write ours as thresholds that stop a release.
What we build on, and when each makes sense.
The right answer depends on how much of the device you need and how many people will maintain it. There is no universally correct choice here.
| Approach | Best when | Trade-off | Maintenance load |
|---|---|---|---|
| Native iOS & Android | You need deep device access — camera, offline sync, background location, biometrics. | Two codebases, two release cycles, two sets of platform reviews. | Highest |
| Cross-platform mobile | The app is mostly forms, lists, and data, and you want one team to hold it. | Occasional platform-specific workarounds; a small performance ceiling. | Moderate |
| Progressive web app | Reach matters more than device integration, and you would rather not fight app store review. | Limited background capability; push support varies by platform. | Lowest |
| Web application | Desktop-first workflows, internal tools, anything with heavy data entry or reporting. | Not installable; offline requires deliberate design. | Low |
We will recommend one of these after the assessment and explain why the other three were rejected for your case.
You see something real in week four.
Not a prototype, not a slide. Something installed on a device that you can hand to a colleague.
Scope & budgets
User flows, platform decision, and the numeric performance and accessibility thresholds we will hold to.
Walking skeleton
One flow working end to end on a real device, through the real backend. Ugly, but genuinely working.
Feature build
Two-week increments on a device you can install. Budgets checked every increment, not at the end.
Store submission & handover
Review submission under your developer accounts, plus the runbook whoever maintains this will need.
The part most proposals leave out.
Mobile applications decay whether or not you touch them. Operating systems ship annually, certificates expire, and platform requirements change with a deadline attached. Someone has to own that.
- Store accounts
- Apple and Google developer accounts stay registered to you. We are added as collaborators and can be removed without disrupting your listings.
- Annual OS releases
- Each September and October brings changes that can break a working app. We budget for that cycle explicitly rather than treating it as an emergency.
- Certificates & provisioning
- Signing certificates expire on a schedule. We document the renewal dates and hand them over, because an expired certificate is an outage.
- Handover documentation
- Written for a developer who has never met us, because eventually that is who will read it.
Tell us what it has to do.
Not which framework — what the thing needs to accomplish and who has to use it. The platform decision follows from that, and we will justify whichever way it lands.