Reselling development to your own clients

Reselling web development means you sell and own the client relationship while a delivery partner builds and hosts the work under your brand. You control scope, communication and margin; they control the build. It holds up only when the contract names who owns the code, the accounts, the uptime and the first response when something breaks at 2am.

Key Takeaways

• Reselling is subcontracting with a client-facing wrapper: your name on the invoice, someone else's hands on the keyboard.
• The three models — white-label, referral and named partner — differ mainly in how much risk and margin you carry.
• Every resold project needs a written answer for ownership of code, domains, DNS, hosting accounts and email.
• You must run your own QA pass before the client sees anything; the partner's "it works on staging" is not acceptance.
• Support is where resellers lose money, so agree response times and escalation paths before launch, not after.
• Keep access in accounts you control, then hand the client clean credentials at the end — never the reverse.

What does reselling web development actually mean?

Reselling web development means your name sits on the contract and your client talks only to you, while another team does the building, the hosting or the maintenance. You carry the commercial risk and the relationship; the delivery partner carries the technical work. In practice it is subcontracting with a client-facing wrapper around it.

The wrapper matters more than the label. Three shapes exist and they behave differently under pressure. In a pure white-label deal, the partner never appears in the deliverable at all — no footer credit, no plugin branding, no vendor name on the invoice. In a referral, you introduce the client and step back, taking a finder's arrangement and none of the delivery risk. In a named-partner arrangement, the client knows a second team is involved and may even meet them.

Why do resold builds fail months after launch?

Resold builds usually fail after launch because nobody defined ownership of the accounts. The site works until the domain renews, the SSL certificate expires, the mail records break, or a plugin update needs a login the client never had. The build was fine; the handover was not.

We have seen this pattern repeatedly: an agency builds a good site, the client pays, everyone is happy. Eight months later the client's email stops working because the DNS zone lived in the reseller's personal Cloudflare account and the reseller changed jobs. Recovering that zone means proving domain ownership to a registrar, which can take days and occasionally fails outright.

The second common failure is silent scope drift. The client asks you for "one small change", you forward it to the partner, nobody records it, and by month six the partner is doing twenty hours a month of unlogged work while you are billing the client for five. Track every request in the same system you use for your own projects, even when the partner does the work.

When should you resell, and when should you just refer?

Resell when the work sits inside a service you already sell and can support, and refer when it does not. If you build WordPress sites, reselling a WordPress build keeps the client in a system you understand. Reselling a custom ERP integration you have never touched puts your reputation behind code you cannot review.

A useful test: could you debug the first production incident yourself, at least far enough to know what to roll back? If the answer is no, refer it. There is no shame in that — a referral that goes well still earns goodwill, and the client comes back for the thing you are actually good at. Choosing off-the-shelf software over custom work is a similar judgement call, and the same reasoning applies when you decide whether to compare custom software against off-the-shelf options for a client with a limited budget.

Which reseller model fits your agency?

The right model depends on how much client contact you want to own and how much delivery risk you can absorb. White-label gives the largest margin and the largest exposure. Referral gives the smallest of both. Named-partner sits in between and suits long retainers where the client wants to meet the people building.

Model	When it fits
White-label	You own the client and the brand; the build partner stays invisible in the deliverable.
Referral	You pass the lead on and step back; lowest risk, lowest margin, fastest to set up.
Named partner	The client knows a second team builds it; suits long retainers and audits.
In-house hire	You need the skill every month and want it on your own payroll instead.

Pick one and write it down. Agencies that drift between white-label and named-partner mid-project are the ones that end up with an awkward conversation about who the client actually hired.

How do you run a white-label delivery week by week?

A white-label delivery runs on a fixed weekly rhythm: one brief in, one demo out, one written status note the client sees. That cadence keeps the partner unblocked and keeps you from becoming a human message queue between two teams who never speak.

1. Write the brief yourself. Screens, copy status, integrations, who supplies images, and what "done" means.
2. Agree the environment split: partner builds in their staging, you get a URL you can share under your own subdomain.
3. Fix a weekly demo slot. A short call beats a long email thread every time.
4. Run your own QA pass on the staging URL before the client sees anything — forms, mobile widths, page speed, broken links.
5. Log every change request in one tracker, tagged by who asked and who pays for it.
6. Plan the handover from week one: which accounts, which credentials, which DNS records move where.

What has to be settled in writing before the first line of code?

Before any code is written, settle four things in writing: who owns the source code, whose accounts hold the domain and DNS, who carries the uptime commitment, and how either side exits. Verbal agreements on these four points are the reason reseller relationships end badly.

Ownership should be unambiguous and in the client's favour at the end — they paid for the work. That does not mean the partner hands over their whole toolchain; it means the client gets a working repository, a database dump and the credentials to run it. Hosting accounts should be in the client's name from day one, with you holding delegated access. When you do transfer a repository between organisations, follow the platform's own procedure rather than moving files by hand, because GitHub's repository transfer documentation covers the redirects and permission edge cases that break naive copies.

Exits deserve a sentence too. What happens to the code and the client if the partner goes quiet, doubles their capacity commitments or simply stops replying? A two-week notice clause and a documented handover checklist cost nothing to write and save months of pain.

How do you verify a build before your client sees it?

Verify a resold build the way you would verify your own work: check DNS resolution, TLS, redirects, form delivery and mobile rendering on the real staging URL, not on a screenshot. If any of those fail, the client will find them within a day of launch.

dig +short www.example.com
curl -I https://www.example.com
curl -I http://example.com

The first command confirms the record points where you think it does. The next two show the status code and whether the HTTP-to-HTTPS redirect is a single hop or a chain. Test the contact form by sending a real message to a real inbox and confirming it arrives — not by watching the success toast. Then check the site on a mid-range Android phone, because that is what most clients hand to their customers.

What breaks in production, and who answers first?

In a resold project, you answer first. The partner may do the fix, but the client calls you, and a client who reaches voicemail twice starts shopping for a replacement. Agree the escalation path and the response window before launch.

Expect three categories. Small things — a broken image, a wrong phone number — should be batched into a weekly fix list rather than interrupting anyone. Medium things — a payment gateway rejecting cards, a form silently dropping submissions — need same-day acknowledgement and a named person on each side. Large things — the site is down, the database is corrupted, the domain has expired — need a written runbook with the actual commands, not a vague promise to "look into it".

One habit that pays off: keep a shared incident log even for tiny problems. After three months you will see whether the failures cluster around one integration or one deploy step, and that tells you what to fix permanently. If you would rather not be the first responder, our team can help you put a support arrangement together — talk to us about the shape of it.

What does reselling cost to operate?

Reselling costs more to operate than the build alone suggests: the difference between what you charge and what you pay the partner has to absorb your QA time, client communication, incident cover and the risk of a fixed-price overrun. Those costs are easy to underestimate.

The drivers are concrete. Partner rates depend on seniority and stack. Your own overhead depends on how many clients you resell to and how demanding they are — a client with a single stakeholder and a clear brief costs a fraction of one with six approvers and a monthly redesign idea. Cloud and hosting costs follow instance size, storage class and egress, and licence fees for page builders or commerce platforms can outlive the project budget entirely. Confirm current numbers with the vendor's own calculator rather than a figure from an old proposal. If you want a realistic view of how a specific engagement would be priced, our pricing and engagement page explains how we scope work.

What does a resold project look like in practice?

A realistic resold project is a mid-sized business site plus a booking flow, built by a partner while you handle the client. It goes well until the client asks for a feature the partner has never built, and the answer is decided by whoever wrote the brief.

Say a trekking operator in Kathmandu needs a new site with an itinerary builder and online enquiries. You take the brief, the partner builds it in a modern stack, and you run QA on staging. Week six, the client asks for multi-currency pricing. The partner quotes extra effort; you check the brief, find currency was never mentioned, and quote the client for a change request rather than swallowing the cost. That single paper trail is the difference between a profitable resold project and a favour you did for free. Our software development team in Nepal works this way with agencies abroad, and the Royal Trek Nepal build shows what that kind of itinerary-led site looks like when it ships.

Which mistakes sink reseller relationships?

Reseller relationships usually die from the same handful of mistakes: undocumented change requests, credentials in the wrong account, no support rota, and a partner who is never named in an emergency. Fix those four and most disputes never start.

• Sharing your own admin login with the client instead of creating them a proper account.
• Letting the partner register the domain in their name "to save time".
• Promising a launch date you have not confirmed with the person doing the work.
• Running updates on production without a backup you have actually tested restoring.
• Assuming the client knows what they are buying when the partner's name appears in a stack trace.

The last one catches people out. If a client sees an unfamiliar vendor name on an error page, they will ask who that is. Have an answer ready — and if you are unsure how much detail to give, the questions we get asked most cover how we handle confidentiality on partner work.

In short: reselling web development is a good business when the wrapper is honest and the paperwork is boring. Own the relationship, keep the accounts in the client's name, run your own QA, and agree the support path before launch. Do those four things and the model scales. Skip them and you are one expired domain away from an awkward phone call.

People also search for

• What should a web development quote include?
• Fixed price or hourly for subcontracted work?
• How do you work with an offshore development team?
• Should a client site be built in phases?
• Shared hosting, VPS or cloud for a resold site?
• How do you report SEO results back to a client?
• Custom software or off-the-shelf for a small business?

If you are carrying client work you would rather not build yourself, our team can help you scope the delivery, run the QA and stay on the hook for support alongside you. Start with the services we cover or send us the brief and we will tell you honestly whether it is a fit.