An agency loses Drupal work when a project needs more Drupal depth than the team carries, or when it arrives while the team is already full. WeebPal builds the Drupal part as your own team. Your client signs with you, talks to you and is invoiced by you. We never contact them unless you bring us into a call, and the work is never published as ours.
Who this is for
Agencies and studios that sell Drupal to their own clients, in situations like these:
- A won project and a full team The work cannot wait for your next free slot, and turning it down sends the client elsewhere next time too.
- Drupal depth you do not keep on staff Custom modules, integrations with the client's systems, a Drupal 7 migration: work that is not worth a hire for one contract.
- An inherited codebase A site built by a team that is gone, with no tests and an update backlog. We read it before anyone promises your client anything about it.
- A client who must see only you Your contract, your brand, your invoices. If the buyer needs to see our name, for a tender or a consortium, that is named subcontracting instead.
What you get, under your name
Each engagement is a defined piece of work at a fixed price, delivered into your repository. What you hold at the end:
- Working code in your repository Custom modules, theme, configuration and migrations, committed to your account from the first commit and written to Drupal coding standards.
- Automated tests Shipped with the code, so a reviewer on your side can check a change without asking us.
- Documentation without our name Written for a developer who has never met us, and free of any mention of WeebPal.
- Demos to you, not to your client Working software on a staging site as the work lands. You decide whether your client sees it, and who presents it.
- A clean exit When the work ends, you remove our access on your side, and you do not need our cooperation to do it.
Sample Handover checklist to your agency Signed off at acceptance, with no WeebPal branding
Code
- Repository in your agency's account
- Release tag matches the site your client runs Checked against the live site
- Build and deploy steps documented
Access
- Our accounts removed from your tracker and repository
- Credentials you issued revoked Confirmed in writing
- No credential of your client's held by us
Documentation
- Content model and editorial roles
- Runbook: deploy, rollback, restore
- Open issues and known risks
An engineer reads it and replies within one business day.
How the work runs
The same steps as a project for a direct client, with one difference: everything that would reach the client reaches you first.
How a white-label project runs
- Discovery Under NDA: the brief, and the repository if one exists, read before anything is sized. Output: the scope notes
- Prototype A design, a clickable prototype or a working demo, at no charge, shown to you first. Output: the prototype
- Fixed price Quoted to your agency once the architecture is agreed. Your price to your client is yours to set. You keep the architecture document
- Build In your tracker and your repository, with a working demo to you each week. You keep the repository
- Acceptance Tested against the scope you agreed with your client, and reviewed by your side. You keep the test record
- Warranty Defects in what we built are ours to fix, under a warranty your agency holds. You keep the handover pack
Protecting the client relationship
What damages an agency in a white-label arrangement is rarely bad intent. It is an email sent to the wrong person during an incident. So the communication rules are written down before the work starts, not during the first outage.
Who sees what in a white-label engagement
What your client sees
Behind your agency
Your brand and your contract
NDA and non‑solicitation
- One route in, one route out Your project contact talks to our engineer. Nobody opens a new channel in the middle of an incident.
- Incidents reach you first We tell you what we know and what we do not yet know. You decide what your client hears, and when, because you are the one who has to say it.
- No trace on the client's side We never invoice your client, never appear in their vendor list, and hold no credential of theirs that you did not issue to us.
The contract clauses behind this, and the order to agree them in, are set out in white-label agency contracts: NDA, non-solicitation and warranty.
When a platform is the shorter route
Some client briefs sit close to a system we already run: a learning platform, restaurant ordering, room or court booking, ticketing. Then the project starts from one of our platforms instead of an empty repository, and we deploy and extend it with you for that client. Your client receives the whole system and its source code. Taking a platform to your own market, beyond a single client, is a platform partnership.
What you can verify
Work we deliver under an agency's brand carries that agency's name, so it is not on this site and we never offer it as a reference. That is the same confidentiality you would be buying. What you can check without asking us for anything:
- Our code in public WE Mega Menu and Component Builder are published on drupal.org, and the issue queue shows how we answer bug reports. The full list is on our open source page.
- Named reviews Agencies that give us Drupal work have reviewed us by name on our reviews page, among them Ingenuity Solution in the United States and Sazae in Australia.
- Our direct client work Projects we deliver to clients directly are published with the client's name, such as SPREP. They show the engineering, not a white-label arrangement.
- One contained piece of work A module, an audit or a migration assessment, before a deadline depends on us. You keep what it produces either way.
We are a U.S-based Drupal development firm and finding a true Drupal talent is always our top priority. We are fortunate enough to work with the WeebPal team.
With a solid technical knowledge foundation, the WeebPal team delivers exceptional work consistently. Granting projects to the WeebPal team gives us some sort of comfort level, since we know the WeebPal folks will deliver no matter what.
What it costs
A white-label project is priced to your agency as a fixed price once the architecture is agreed, and your price to your client is yours to set. The project sizes on our pricing page, from Micro to Strategic, show how a project is scoped and staffed, and the Rate Card gives the rate for each role.
What moves the number: how much of the codebase already exists and in what state, the integrations that have to keep working, whether content has to migrate, and the evidence your client's acceptance asks for. An existing codebase is read before it is priced.
Ongoing care of a live client site is billed by the month instead, as white-label support, and a backlog that never empties suits a dedicated team. If the system is for your own organisation rather than a client, see outsource Drupal development. Answers to the questions agencies ask before signing are in our FAQ for agency partners.
Terms that hold
These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.
- A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
- You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
- Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.
Agency terms
Agreed in writing before any work starts, and the same for every agency we work with.
- NDA first A mutual NDA is signed before a client name, a requirement or a repository changes hands.
- Non-solicitation, both ways We do not approach your clients or hire your staff, and you do not hire ours. The clause is written into the contract, for the term the contract sets.
- The warranty is held by your agency On development projects the warranty belongs to your agency, as the party that signs with us: 1 year by default, up to 3 years, including the security releases of Drupal core and contributed modules. What you promise your own client is yours to set.
- Code delivered to your agency The code goes into your repository, and your client receives the whole system and its source code under your contract with them.
- Platforms, taken to market together When a client's system runs on one of our platforms, we deploy and extend it with you for that client, and we grow that market together.
- You decide who appears As a white-label team we never appear to your client. As a named subcontractor, on a tender or in a consortium, we appear under our own name where you want us to. Either way, you decide who joins a client call.
Questions we get asked
What if our client asks who built it?
That is your answer to give. Our agreement says we are not named to your client and we do not contact them on our own, so nothing from our side contradicts what you tell them. If the client or a tender needs the subcontractor named, that is named subcontracting, agreed as such before the work starts.
Can one of your engineers join a call with our client?
Yes, when you want one there: as part of your team, on your call, with your introduction. You brief us beforehand on what the client knows, and follow-ups come back through you.
Can you pick up a half-finished build from another team?
Usually. We read the repository first, then write down what works, what does not and what it would take to finish. That assessment is yours to keep, and the fixed price for the rest is set on what the code shows rather than on the original plan.
Do you also work for agencies that compete with ours?
We work with agencies who also sell Drupal, sometimes into the same market. Each engagement runs under its own NDA, nothing from one client's work moves to another, and non-solicitation covers your clients and your staff. The clause is written down precisely because this happens.
Does anything we deliver mention WeebPal?
No. Documentation, demos and reports carry no mention of us, and the code carries no WeebPal branding. Our engineers commit under the accounts you create for them in your repository.
Can our own developers take over after launch?
Yes, and the work is built to pass that test: code to Drupal coding standards, automated tests, documentation written for someone who was not there, and a repository and deployment you already control. The end of an engagement is something you do, not something we grant.
Not covered here? Ask us directly.
Talk to an engineerAn engineer reads it and replies within one business day.
Talk to an engineer under NDA
Describe the project in a few lines. The NDA is signed before the brief, the repository or your client's name changes hands.
An engineer reads it and replies within one business day.