We map what you do now
Before anything gets built, the current process goes on paper. Every manual step, every handoff, every place the same information gets typed twice.
How we work
The paperwork, published before you pay for any of it.
This page exists because the alternative is asking you to trust a stranger with a budget. Everything below is how the work actually runs, taken from the agreement rather than written to sound good.
Three steps, and you keep the keys.
We build the first version
Scope fixed in writing, exclusions named. A change request carries a price and a date before it is approved, not after the work is done.
We hand you the keys
Source code, domains, accounts and documentation, transferred in writing. One recorded walkthrough. Thirty days of defect fixes.
What the scope document says.
Every project gets one before any code is written. Six sections, every time.
It is short, usually two pages. Length is not the point; specificity is.
What is being built
Named screens, named integrations, named user roles. Not 'a website' but the specific pages, and not 'a CRM' but the specific records and who can see them.
What is not being built
The exclusion list. This is the part most quotes leave out, and it is the part that causes every argument later.
What we need from you, and when
Content, logins, approvals, a named decision maker. Each with a date. A project stalling on a missing password is still a project stalling.
Fees and payment points
The total, what triggers each invoice, and the payment term. Exclusive of tax, stated separately.
Dates
Start, first review, target completion. Dependent on the items above arriving on time, which is stated rather than implied.
Warranty period
How long after handover defects get fixed at no charge, and what counts as a defect rather than a change.
When the work changes, and it will.
Scope changes on almost every project. The difference between a healthy project and a bad one is whether the change was priced before it was built or argued about afterwards.
You ask, or we flag
Either side can raise it. If we notice the work drifting outside the scope, we say so at that moment rather than absorbing it quietly and running out of time later.
We price it and date it
A short written note: what changes, what it costs, and what it does to the timeline. Usually within one working day.
You approve, or you do not
Nothing gets built until it is approved in writing. Declining a change is a normal outcome and does not affect the rest of the work.
A defect is not a change. If something we built does not do what the scope said it would, that is our problem and it gets fixed at no charge, inside the warranty period or outside it.
The payment rhythm.
No figures on this page, because the number depends entirely on the work. The structure, though, is always the same.
On signing
A deposit against the first stage. Work starts once it clears, not before.
At the milestones
Tied to delivered stages named in the scope, not to dates on a calendar.
On handover
The balance. Ownership of everything transfers on payment in full.
Invoices carry a number, a tax line where it applies, and a payment term. Late payment has a stated consequence in the agreement rather than an awkward conversation.
Handover means you can leave.
A studio that keeps hold of your domain, your repository or your deployment account has not delivered a system. It has taken a hostage.
What transfers to you, in writing
- The source code repository, with full history
- Domain registrar and DNS control
- Hosting, database and third-party service accounts
- Environment variables and credentials, rotated at handover
- Technical documentation and a runbook
- One recorded walkthrough of the whole system
We keep the right to reuse our own general-purpose components, the ones that existed before your project. Your business logic, your data and your deliverables are yours.
Read all of that and still want to talk?
Then you already know how this works, which makes the first call much shorter.