Our app development process: how a project actually runs, from the first message to the version after launch.
1. You tell us the idea
A few sentences is enough to start. What it should do, who it is for, and anything that already exists — a spreadsheet, a manual process, an older app. We read every enquiry ourselves.
2. We tell you what we think
Before anything is agreed, you get an honest read: whether it is a good fit for us, roughly what it involves, and which part we would build first. Sometimes the answer is that you do not need an app at all, or that the useful version is much smaller than the one you described. We would rather say that early than take the work and find out later.
3. The smallest version that proves it
We build the core of it first — the part that has to work for the whole thing to be worth having — and put it in your hands early. Deciding what to cut is easier when you are holding it than when you are reading a specification.
4. Build, in versions you can see
Work goes out in builds you can install and use, not screenshots. You see progress as it happens, and changing direction stays cheap because nothing has been polished before it was proven.
5. Shipping
Getting to the store is its own piece of work: review guidelines, privacy declarations, store listings, screenshots for every device size, and the rejections that come back for reasons nobody warned you about. We have been through it repeatedly with our own apps, so it is a known process rather than a surprise.
6. After launch
An app is not finished when it ships. Apple releases a new OS every year, APIs change, and the first real users find the things testing missed. We keep our own apps updated and can do the same for yours, or hand over cleanly if you would rather take it in-house.
What we ask of you
Someone who can make decisions, and answers within a few days. Projects stall on waiting far more often than on building.