The build partner your client never has to meet

Your client contracts with you, is invoiced by you, and communicates with you. We build, document and hand over, and appear in front of your client only if you invite us — some agencies prefer us silent, others bring us in as their named technical partner, and both work as long as it is decided in advance rather than improvised on a call. Deliverables carry your branding, the code is yours, and there is no attempt to convert your client into ours.

• You own the client relationship and the commercials
• We appear only if and how you choose
• Code and repositories belong to you or your client
• No approach to your client, during or after

Bringing in a build partner makes sense when the work needs WooCommerce depth, storefront performance engineering or a migration with real SEO risk — the kinds of project where an unfamiliar developer's learning curve is billed to your margin. It makes less sense for small maintenance tasks, which are usually cheaper to keep in-house. The honest test is whether the project has a failure mode that would embarrass you in front of the client; those are the ones worth handing to someone who has done it before.

You get a written scope with a fixed price for defined work, expressed in enough detail that you can build your own quote on top with a margin you control. Where the scope has genuine unknowns — an existing plugin stack nobody has audited, a catalogue of unclear quality — the estimate says so and prices an audit first rather than pretending certainty. Change requests are quoted before they are built, so a client's mid-project idea does not quietly consume your margin.

We work in your repository or ours, whichever you prefer, with a branch and review flow that matches your team's. Staging environments, deployment and handover documentation are part of the deliverable rather than an afterthought. If you have QA, we build to be tested by it; if you do not, we say what we tested and what we did not, so nobody discovers an untested checkout path from a customer complaint.

This is the part that most often sours these arrangements. Agree before the build: how long post-launch support runs, what counts as a defect versus new work, what response times apply, and what happens when the client emails at 6pm on a Friday because checkout is down. Both continuing support and a clean handover to your own team are workable — what does not work is discovering the answer during an incident. The maintenance and support page describes the shape of an ongoing arrangement if that is the route you choose.

We will not promise your client rankings, conversion percentages or a perfect performance score, and we will not write those into a proposal you are going to sign. If a client's expectation is unrealistic, you will hear it from us before the contract rather than after the launch. That is occasionally inconvenient in a sales conversation and consistently cheaper than the alternative, which is an unhappy client and an argument about whose promise it was.

The sensible first engagement is a small, well-defined piece of work — a performance audit, a single template rebuild, a migration plan rather than the migration — so both sides can see how the other communicates before anything large is at stake. If it works, scale up. If it does not, you have spent a small amount finding out. Any partner who resists starting small is telling you something about how they handle risk.