White-label web development, under your brand

Yes, we can sign an NDA. Send yours over and we will arrange it before any brief or client detail changes hands. NDAs are available on request, and we are used to agencies asking for one before the first call. It fits how the engagement works in any case. We are contracted by your agency, our agreement is with you, and we have no agreement, no invoice and no relationship with your client. Nothing we build carries our name, and progress goes to your team rather than to the client. If your NDA needs to cover the repository, the designs, the client’s data and the fact that we are involved at all, that is normal. Send it with the brief and we will return it signed, so the paperwork is done before the scoping conversation starts.

Your client will not know we exist from anything we produce. Nothing we build carries our name. There is no credit link, no footer mark and no admin badge, and we do not contact your client. Our agreement is with your agency, and we have no agreement, no invoice and no relationship with the client. Progress goes to your team, and the handover documentation is written in neutral language you can rebrand. Whether you tell the client that you use a build partner is entirely your decision. Some agencies do, most do not, and it changes nothing about how we work. If you want us on a technical call, that happens at your invitation and under your introduction. Otherwise you keep the client relationship, the scope conversation and the presentation, and we keep the build.

No, you do not have to change how you run projects. We work to your process, your tools and your terminology. If your team lives in Jira, we are in Jira. If your client’s approvals happen in a weekly call you run, we build around it. We follow your repository conventions, branch names and documentation format, and work can land in your repository or ours, whichever you prefer. You brief us in whatever format you already use: a Figma file, a client scope document, a Slack thread or a bug list. You do not need to rewrite it for us. What we add is a written scope before the build, a fixed check-in rhythm and one named point of contact, so nobody on your side has to chase for status. Everything else stays the way your agency already does it.

You own the code, on handover. You get the full repository, with no licence conditions of ours attached to it. Handover is a deliverable rather than an email. It includes the repository with a readable commit history, a README that tells your team how to run it, deployment and build instructions, and the environment variables the site needs. You also get a short written guide for whoever edits the content, written in neutral language you can rebrand, and a walkthrough call with your team. After that the code is yours to change, host and present as your own. You are not locked into us to maintain it. If you would rather we kept running it, support and maintenance is a separate, optional agreement, and nothing in the codebase only works while we are involved.

If you hold a support agreement with us, a fault after handover is covered under our SLA. If you do not, you can still send it to us. It goes into the queue as new work rather than as an incident, so it is scheduled alongside other projects rather than picked up under a response commitment. Agencies that resell care plans to their clients usually take the support agreement, so the escalation path exists before it is needed. That agreement is separate from the build and optional, and it can be run under your brand as your care plan. Handover also includes a list of anything we deliberately left out of scope, so a missing feature does not surface later as a fault. Either way, the repository and documentation are yours, so another developer could pick the work up if you preferred.

We handle scope changes the same way you would want your own developers to. Anything outside the written scope comes back to you as a short note with the cost and the schedule impact before we build it. You then decide whether to absorb it, bill your client, or drop it. The written scope you receive at the start sets out what we will build, what we have assumed, what we need from you and what is explicitly not included, so it is clear when a request falls outside it. Changes inside that scope are simply part of the build. Because work lands on a fixed check-in rhythm with one named point of contact, changes tend to surface early rather than at the end. If something in the original brief will not work, you hear it at scoping, before you have committed to a date with your client.

Yes, we can work directly with your client when you put us in the room. Some agencies want us on technical scoping calls or handover sessions because it is faster than relaying. That happens at your invitation, under your introduction, and it stops when you say it stops. Our agreement stays with your agency throughout. We have no agreement, no invoice and no relationship with your client, and we do not contact them outside the sessions you arrange. By default we do not join a client call unless you put us in it, and progress goes to your team. You keep the client relationship, the scope conversation and the presentation. Being in the room for a technical question does not change any of that, and it does not turn into a second relationship that runs alongside yours.

How quickly we can start depends on what is already in the schedule. That is why the first call is short and specific: a 30-minute call about the work you have on, rather than a pitch. Send the brief in whatever form you have it and we will come back with a written scope, what we have assumed, what we need from you and a realistic start. If we cannot hit the date you have promised your client, you will hear that on the call rather than in week three. We are capacity when the work is there and nothing when it is not, with no recruitment and no notice period, so a start is usually a scheduling question rather than a hiring one. Rescue work is often how an agency first works with us, when something is broken and the deadline has not moved.