How a project runs
Every project runs in four steps: the brief, a written plan and estimate, milestones that each end with a link to the working build, and the handover. You can see each one.
1. The brief
You tell us what it must do and who will use it (Writing your brief covers the form field by field), and we reply with questions or a time for the free call.
2. The written plan and estimate
You'll see the plan, the price and the first milestone before we write a line of code.
The estimate is a written document, in plain words. It covers:
- The plan: what we'll build, split into milestones.
- The price: for the whole job, with the package it falls under.
- The payment schedule: when each payment is due.
- The running costs: what the product costs to run after launch, listed apart from the price. Packages explained covers what they include.
Every brief gets its own plan and estimate, written after we've read it, so the milestones in it are the ones your project needs.
Then you decide. Nothing is built until you say go.
3. Milestones, each with a link
A status report tells you what happened. A link lets you check.
Each milestone ends with the build itself, working, so you open it, sign in, tap through the new screens, and tell us what feels wrong while it's still cheap to change. What the link opens depends on the work:
| Work | What a milestone ends with |
|---|---|
| Web apps | a link to the web build, live in your browser |
| Mobile apps | a link to the web build, plus an Android build you install on your own phone |
| Browser extensions | a build you load into your own browser, then try on your sites |
| Desktop apps | an installer you run on your own machine |
| Graphic design | a link to the files, shown on real screens, like a phone home screen or a store page |
| Video editing | a link to the current cut, so you watch it where it'll play |
| QA testing and automation | a link to the results, where every failure links to the screen that failed |
| AI features and automation | a link to the working feature, tried on your own examples |
On software we build, testing happens inside every milestone, not as a phase at the end. It's part of the price.
4. Handover
Everything you paid for moves into your name at the end: the code repository, the design files, the store and hosting accounts, and every credential the product needs. It's a standard term in every package, and the accounts can be yours from day one, or test accounts you replace. What you own at handover lists it all by kind of project.
What if the scope changes halfway?
We re-estimate the change in writing before we build it, so the price never moves without you agreeing. The new estimate shows what the change adds to the price and to the milestones.
Changing your mind isn't a failure. It's usually what a milestone link is for. A screen you've clicked through tells you more than a spec you've only read, so expect to want something different once you've used it yourself.
And after launch?
You choose. Maintenance and updates come as a monthly add-on, priced in your estimate. Ask for it in the brief, and the estimate lists it next to your running costs, so you see the whole monthly figure in one place. If you'd rather take it from here yourself, or hand it to another team, the handover already gave you everything you need.
See it on a real product
Our own products are the clearest example of what a milestone link feels like. The example on the home page opens ZTools on the web, the FilesHub product site and ZTools on Google Play, each one live today.
See the example (opens in a new tab)
Next: Packages explained: which package fits your project, and what gets its own estimate.