9io.ai / How we work
How we work, written down.
Every engagement runs the same way, whatever we're building. These are the terms — the same ones that appear in your proposal, before you sign anything.
By the hour, for the people doing the work.
Hourly, for real people
The proposal lists each person, what they'll do and how many hours we expect it to take. You pay for those hours. Nothing is added on top for managing the work.
Invoiced twice a month
Each invoice covers work that is already done, and points at the checkpoints you can open and look at. If something slips, it moves to the next invoice instead of being billed on trust.
10% waits for you
We hold back a tenth of every invoice until you've accepted the milestone. It keeps acceptance meaningful and keeps the amount at stake small for both of us.
Small things are free
Copy changes, design tweaks and SEO adjustments are part of the job, not a billing event. We only raise a change order if the scope or the timeline genuinely moves, and we talk to you first.
We don't publish rates, because the honest number depends on which roles you need and for how long. They're in the proposal before you commit to anything.
You watch it happen, rather than hear about it.
The risk in hiring a team is a long silence followed by a big reveal. So the work is cut into short stages, and something real lands in front of you throughout.
- A staging link early. A working environment and a login near the start of the build, not at the end, so you're reacting to the real thing while changing it is still cheap.
- Something to open every second stage. While you're reviewing it, the team is already into the next one, so nothing sits idle waiting for a reply.
- A short update every Friday. What shipped, what's next, what's blocked and who owns it. Short enough to actually read.
- Seven days to review. Each checkpoint gets seven working days against criteria agreed before the work started. If something misses, we fix it at our cost.
Everything, as you pay for it.
- Your repository from day one. Code, history and infrastructure definitions live with you from the first commit. There's no handover at the end because nothing was ever kept on our side.
- Ownership transfers as you pay. Rights pass milestone by milestone, and until then you hold a licence that can't be revoked — so the work is never held up by a commercial question.
- A 90-day warranty. If delivered work is defective within 90 days, we fix it.
- Written so someone else could take over. The architecture is documented and the runbook kept current, so an in-house team or another studio can pick it up without calling us.
Scale up, scale down, or stop.
- Three sizes. Reduced, full and accelerated differ in how many people are on the work and how fast it moves — never in who does it or how carefully.
- Changing size takes 30 days' notice, at a month boundary, so nobody is left half-committed.
- The first block stands alone. At the end of it you hold the architecture, a working foundation and a firm price for the rest. Carry on with us, take it to another team, or stop — there's no retainer to unwind.
The things that usually turn up as invoices later.
Where they apply to what you're building, these are part of the job rather than an upsell after launch. A team that leaves them for "phase two" is handing you something unfinished.
Analytics
Set up during the build, so the product can answer questions about itself on day one.
Technical SEO
Sitemaps, metadata and structured data handled as we go, not retrofitted by another agency.
Fast delivery
A global CDN and a performance budget enforced while the code is written, rather than audited after it's slow.
Alerting
Uptime and error alerts wired up before launch, so a failure reaches a person instead of a customer.
Accessibility
A WCAG AA baseline designed in and checked in QA on every checkpoint, instead of retrofitted under legal pressure.
Email that arrives
SPF, DKIM and DMARC configured and verified, so your transactional mail reaches inboxes.
Consent handling
A cookie and consent banner that behaves according to where the visitor actually is.
Tested backups
Backups configured and a restore actually performed. An untested backup is a belief, not a recovery plan.
Documentation
The architecture written down and a runbook for the failures you can reasonably expect.
Tell us what you're building.
A few lines is enough: what it is, where it's at, and what's missing. You'll get a straight answer about what it would take — and if we're not the right fit, we'll say so.
Replies come from the person who'd do the work.