Five stages, and what each one actually requires from both sides. The people who scope the work are the people who build it, and progress is visible throughout rather than revealed at the end.
The process
We work out what the problem actually is — which is not always what the initial brief describes. That means understanding the business process, the people who use it, the systems already in place, and what a good outcome looks like in terms you would recognise.
Features, architecture, deliverables, milestones, assumptions and cost, agreed in writing before any development begins. Assumptions are written down explicitly, because that is where projects usually go wrong — not in what was agreed, but in what each side assumed.
Design and development in visible increments. You see working software regularly rather than a status percentage, because a demonstration is harder to be vague about than a progress report.
Testing, deployment, production setup, store submission where it applies, and the documentation to go with it. Accounts and infrastructure are created in your name, so nothing needs transferring afterwards.
Fixes, enhancements, monitoring and continued development for as long as it is useful. Equally, if you want to take it in-house, the documentation and ownership position are designed to make that a real option rather than a theoretical one.
Engagement models
These are the only three we offer. We do not sell staff augmentation, hourly billing, or support retainers that exist to be paid for and never used.
For projects where the requirements are still unclear.
A standalone piece of work with its own fee. You can take the output to any developer — including not us.
For projects where the deliverable is clearly defined.
Most engagements. Changes are scoped and priced as a variation rather than absorbed silently.
For evolving software that needs continued product work.
Suits a product still finding its shape. Not a retainer for being on call.
What it costs
Most firms will not publish this. The figures below are the same ones on our directory profiles, and they are a floor and a band rather than a price list — the exact number comes from scope, which comes from discovery.
Most fixed-scope projects start here. Smaller pieces of work are possible where the scope is genuinely narrow — an integration, or one process automated.
Used for ongoing development and for work that cannot sensibly be fixed-scope. A rate on its own tells you little: a $90 developer who needs 400 hours costs more than a $150 developer who needs 200.
A standalone piece of work with its own fee, agreed before it starts. You keep the output whether or not you build with us.
Worth reading before you budget: what custom software actually costs sets out what moves a project between those numbers.
What we commit to
None of this depends on us having a track record. They are commitments we can make today, and they answer the question worth asking of any developer: what happens if this goes wrong.
Source code, infrastructure and accounts are yours throughout, not transferred at the end on good behaviour. It lives in your repository and runs in your accounts.
For fixed-scope work the number you approve is the number you pay. If something in the scope turns out to be wrong, that is a variation we price and you approve — not a surprise on the invoice.
Ongoing work is cancellable with notice. There is no minimum term, no auto-renewal, and no exit fee.
Documentation is written for whoever comes next, including a developer who is not us. We do not make ourselves difficult to replace.
No account manager relaying messages. The person who scoped the work is the person writing the code.
Get in touch
The first step is always discovery, and that begins with you telling us what is not working. No specification required.
