Service overview
An app is a much larger promise than a website, and most of what goes wrong is agreed in the first fortnight: a feature list nobody pruned, a scope written to be signed rather than built, and a launch date picked before anyone knew what was in it.
So we cut the first release down to the thing it has to do, build that properly, and put it in your hands early enough that changing your mind is cheap. Everything else goes on a list for the version after: a real list, not a polite way of saying no.
What's included
One scope, agreed in writing before anything starts, covering design, build, store submission and the first stretch after launch. If the scope grows we agree it with you first, so there is no invoice you have not already seen.
The first version should be embarrassingly small and genuinely finished. A large unfinished app teaches you nothing, and you cannot ship it.
- Scoping down to a first release
- Screens and flows before any code
- iOS and Android from one codebase
- Accounts, payments and notifications
- Offline and poor-connection handling
- Store listing and submission handled
- Crash reporting from day one
- Source code handed over, in full
How it looks in practice
Two builds from the studio's own shelf. Different jobs, same order of work: the shortest path to the thing the app exists for, and nothing standing in front of it.
Frequently asked
The four that come up on nearly every first call. If yours is not here, ask it. You will get a straight answer, not a brochure.
More than a website, and less than the number you have probably been quoted. It turns entirely on the first release scope, which is why we scope before we price, so you get a fixed figure against a written list, not a day rate and a shrug.
Both, from one codebase, unless there is a reason not to. Two native builds cost close to double and are only worth it when you need something the shared route genuinely cannot reach. We will tell you when that is the case rather than selling you the bigger job.
A focused first release is usually three to five months, and store review adds a week or two on top. You see working builds on your own phone long before that, at every stage, so the launch date ends up the least surprising part of it.
The first stretch of fixes is included: the things only real users find. After that you can keep us on for updates or take the code and run it yourself. It is yours either way, with the repository and the deployment already in your name.