How we work
This page is for whoever has to run the project. Five stages, one named contact, and a written answer at every point about who owns what. If you have used a subcontractor before and spent your week chasing them, this is the part you should read closely.
Who owns what
Most of the friction in white-label work comes from an unstated assumption about who is doing something. So it is stated.
Client relationship
Yours, entirely
None
Commercial terms with your client
Yours
Not our business
Design
Yours, unless you ask us to scope it
Built to your files
Technical decisions
Sign-off
Proposal and reasoning, in writing
Scope definition
Approval
Written scope, assumptions, exclusions
Build and code quality
—
Ours
QA against the scope
—
Ours, before it reaches you
Client-facing UAT
Yours
We fix what comes back
Presentation to your client
Yours
We do not attend unless you invite us
Deployment
Your call — you or us
Either, documented
Ownership of the code
Yours at handover
None retained
Five stages, and what each one costs you in attention
One named contact from the first message to the walkthrough call. Nothing below is a stage you have to chase us through.
The brief
Send what you already have. A Figma link, a client scope document, a proposal you have already sent, a bug list, a Slack thread. You should not have to write a second brief for your build partner.
If something is missing we ask for it once, in one message, as a list — not in six emails over four days. The three things most often missing are the content, the real data volumes, and what has already been promised to your client. If you do not have them yet, say so and we scope around the uncertainty rather than pretending it is not there.
The scope
You get back a written scope before anything is built. It contains four things:
- What we will build, in enough detail to check against your client’s expectation.
- What we have assumed, because assumptions are where fixed prices go wrong.
- What we need from you, and by when, for the dates to hold.
- What is not included, explicitly.
That last section is the one that matters. A scope that lists only what is included is a scope you will end up arguing about.
If the brief cannot be built as described — the design does not work at a real breakpoint, the integration the client assumed exists does not, the deadline is not achievable — you hear it here. Before you have confirmed anything to your client, while it is still a scoping conversation rather than an apology.
The build
One named contact.The same person for the whole project. You are not routed through an account manager and you are not reintroduced to a new developer in week three.
Your tools.Jira, Linear, Trello, Basecamp, a shared Slack channel, email. We work in whatever your team already uses. If you have no preference, we will propose one and it will be simple.
A fixed check-in rhythm.Agreed at kick-off — usually weekly, more often on short or high-risk work. The point of a fixed rhythm is that you never have to ask for status, which is the specific behaviour that makes managing a subcontractor exhausting.
Visible progress.Work goes to a staging environment you can look at whenever you want. You do not have to wait for a demo to see where it is.
Changes come back before they are built.Anything outside the written scope returns to you as a short note with the cost and the schedule impact. You decide whether to absorb it, bill your client for it, or drop it. We do not silently build it and we do not silently skip it.
QA
We test before it reaches you. Against the scope, on real devices and current browsers, with realistic content rather than lorem ipsum, and with the data volumes the site will actually carry.
Accessibility basics are part of QA, not an extra: semantic structure, keyboard operation, visible focus states, and text contrast that passes. If your client’s brief specifies a WCAG level, tell us at scoping and it becomes a test criterion with evidence attached.
Then you test it, and your client tests it. Feedback comes to us through you, in one list, in one place. A UAT round with three sources and two channels is how a week disappears.
Handover
Handover is a deliverable with a definition, not an email with a zip file attached.
- The repository, with readable history and a README that lets your developer run it.
- Build and deployment instructions, and the environment configuration the site needs.
- A written editor guide for whoever maintains the content — neutral in tone, unbranded, yours to rebrand.
- A walkthrough call with your team, so the person taking it over has spoken to the person who built it.
- The out-of-scope list, so nothing surfaces later as a surprise.
After handover the code is yours. There is no licence, no retained component and no dependency on us. If you would rather we kept running it, that is a separate and optional support agreement.
Who talks to whom, and how often
One channel, one thread, one named person. The failure mode we are designing against is you chasing us for a status.
Through you, always.You brief us, we report to you, and your client hears from you.
In your voice when it is client-facing.Reports, editor guides and documentation are written to be forwarded without editing. Nothing in them carries our name.
In the room when you want us there.Some agencies bring us onto technical scoping calls or handover sessions because relaying detail is slower than having the developer speak. That happens at your invitation, under whatever introduction you choose, and it stops when you say it stops.
Written when it matters.Decisions, scope changes and technical recommendations are confirmed in writing. Not because of bureaucracy, but because six months later somebody will ask why the site does something and the answer should exist.
When something goes wrong
Projects go wrong. What distinguishes suppliers is what happens in the twenty-four hours after.
You hear it from us first.If a date is at risk you find out while there is still time to act, not on the day. Late news is the thing that damages your relationship with your client, and it is the thing we are most careful about.
With options, not just a problem.What can be cut, what can be deferred, what can be resourced differently, and what each costs.
In writing,if it changed the scope or the schedule.
For live sites under a support agreement there is a defined escalation path and a published response commitment — see the SLA.
Confidentiality and your client
This is the question every agency asks, so it gets its own section rather than a line in an FAQ.
Nothing we build carries our name — no credit link, no footer logo, no admin badge, no comment in the source with our URL in it. We do not contact your client, pitch them, or take work from them. The only time we speak to your client is when you have put us in the room.
Whether you tell your client that you use a build partner is entirely your decision. Some agencies are open about it; most are not. It changes nothing about how we work.
Questions delivery leads ask
Will I have to project-manage you?
No. One named contact, a fixed check-in rhythm, staging you can look at any time, and scope changes that come to you before they are built. Chasing for status should not be part of your week.
What if our designer and your developer disagree?
It comes to you with both positions and a recommendation. Your designer’s intent wins by default; where it cannot be built as drawn we say why and propose the nearest thing that can.
Can you work inside our project management tool and our Slack?
Yes. Working in your tools is normal and preferred — it is how your team keeps visibility without asking for it.
What if our client changes their mind halfway through?
They will. It comes back to you as a note with cost and schedule impact, you decide, and we build the decision. The only version of this that goes badly is the one where nobody writes it down.
How much notice do you need to start?
It depends on the schedule at the time, which is why the first call is short and specific. If your date is not achievable you hear that on the call.
What happens if we stop working together mid-project?
You take the repository and the documentation in whatever state they are in, and we write up where things stand. There is no hostage-taking in the handover.
Book a partner call
Thirty minutes, about a real project. Bring the deadline and the part you are least sure about.