How the work actually goes
A one-person practice building mobile apps for Android and iOS, run by a software engineer whose previous work was on applications serving millions of users in telecommunications and fintech.
How a project runs
Five stages, none of them handed to anyone else. The unglamorous ones are where most projects come unstuck, so they are described here rather than assumed.
Idea
We start with the problem rather than the feature list. The app that gets built is often smaller than the one first described, because talking through what it is actually for removes things nobody would have missed.
Analysis
What it has to do, what it deliberately does not, and what that costs. You get a scope you can read and a price for it before anything is built.
Development
Delivered in visible pieces rather than disappearing for three months. You watch it working as it grows, which is while changing your mind is still cheap.
Store release
Store listings, screenshots, privacy declarations, age ratings, review submissions, and the rejections that sometimes follow. This part surprises people who have not done it before. It is included.
Maintenance
Operating systems move every year, and an app that is never touched again eventually stops working. Support is arranged separately once we both know what the app actually needs, rather than guessed at up front.
The questions that come up first
- How is it priced?
- Per project, not by the hour. You know the number before anything starts, and an estimate that turns out optimistic is my problem rather than yours — which is the right way round, since I am the one who made it.
- What do you need from me to start?
- An idea and a conversation. There is no need for a written specification; producing one is part of the work, not a prerequisite for it.
- What if I change my mind halfway through?
- Expected, and the reason the build arrives in visible pieces. Small changes are absorbed. Anything that moves the scope is re-quoted before it is built rather than discovered afterwards.