Someone is deleting your app right now.
Not because it is ugly. Because it takes too long to open on the phone they actually own, it shipped with everything nobody asked for, and the fix never came. The team who built it had already moved on. Your app does not die at launch. It dies in month fourteen.
What is already wrong
You have either a half-finished app or a specification that has not stopped growing. Three things are almost always behind it.
- 01
Nothing was left out
Every request from every meeting went into version one. The build is nearly there. Your budget is not, and half of what is in it answers a question you stopped asking in week three.
- 02
It was tested on the newest phone
The one it was written on. Your customers are two or three handsets behind that, on a mid-range Android with one bar of signal. It takes long enough to open that they do something else.
- 03
Nobody planned the second release
Shipping is not launching. There is a review queue, a crowd of users who will never update, and a backend now answering two versions of your app at once. None of it was in the quote you signed.
What you need
Six shapes of work. Nearly every project is one of them plus a piece of a second. Knowing which one before anyone quotes is what stops you paying for the other five.
Mobile apps
iOS and Android from one build, unless there is a reason not to
Internal tools
The thing your team currently runs on a spreadsheet and three chat groups
APIs and integrations
The layer your app, your site and your billing software all read from
Data modelling
Settled before the first screen, because it is the part you cannot redo cheaply
Infrastructure
Where it runs, what it costs a month, and what happens when usage doubles
Half-built rescues
Someone else started it, the original team is gone, and it still has to ship
What you get, and when
Six phases, in this order, every time. Each one ends in something you can hold: a document, a prototype, a build on your own phone. You are never asked to take progress on trust.
Scope
The argument is about what stays out of version one. The deferred list is normally longer than the build list, and writing it down is what stops the same feature coming back in month four.
You end with
A build list, and a second list of everything that waits.
Design
Every screen, and the route between them, clickable before a line of it is built. A dead end costs an afternoon here and a fortnight in week nine.
You end with
A prototype you can hand to someone without narrating it.
Build
Two-week blocks. Each one ends with a version installed on your phone rather than a screen recording of one, so you are judging the thing itself.
You end with
A build on your device every fortnight.
Test
Real handsets, older operating systems, bad connections, and the states nobody demos: no signal, empty account, expired session, payment declined.
You end with
The device and OS list it is signed off against.
Release
Store submission, the review queue, and a staged rollout rather than a switch. Crash reporting goes live before the first user, not after the first complaint.
You end with
It is in the store, and you can see it the moment it breaks.
After
A new OS version every year, a backend serving two app versions at once, and the features that were deferred in phase one, taken in order.
You end with
A release cadence, and a named person who answers.
What runs now
Three platforms built end to end and running today for other businesses. The gym one has a member app you can open from this page.
Gym management platform
Multi-role SaaS · gyms and studios
Reception checks members in by QR, trainers see who actually turned up, and the owner reads revenue and renewals per branch without asking anyone to pull a report. Members get the same system as an app on their phone.
- QR check-in
- Memberships and renewals
- Class booking
- Four role views
- One build, three platforms
Spa management platform
Cloud SaaS · wellness
Every branch, room and client in one system. Bookings that know which room is free, a client history the therapist reads before the appointment, and the week in numbers sent to the owner without anyone opening a dashboard.
- Multi-branch booking
- Live room status
- Client history
- Inventory
- Scheduled reports
E-commerce automation pipeline
Automation · retail
A pipeline that pulls product data, cleans and enriches it, then publishes to Shopify with the spec sheet generated on the way through. Built for a catalogue far too large to keep current by hand.
- Scheduled scraping
- Enrichment
- Shopify publishing
- Generated PDFs
After the store approves
This decides whether your app is still installed a year from now. It is the part almost nobody puts in a quote.
Crash reporting
Wired in before release, so a crash on a handset we have never held reaches us the same day, with the stack trace attached.
OS releases
iOS and Android each ship a version every year that breaks something. We test against the betas instead of reading the release notes afterwards.
Two versions at once
Your users do not update. The backend keeps serving the version they installed last year while the new one rolls out, and both keep working.
Store submissions
Every update goes back through review. Rejections are usually about a screenshot or a privacy label rather than the code, and we handle them.
Send us whatever you have
A specification, a Figma file, or three paragraphs and an app you like. We will come back with what belongs in version one and what should wait, before you decide whether to work with us.