Agencies rarely have a Drupal problem. They have a capacity problem that arrives in bursts: several wins in the same quarter, a developer who resigns mid-build, a client roadmap that suddenly needs more people. Hiring against a burst is slow and leaves a bench when it ends. Drupal staff augmentation is the other answer: a dedicated team of named WeebPal engineers, reserved for your agency by the month as overflow capacity, directed by you, and scaled with notice rather than redundancy.
A reserved team inside your process Example composition; each team is built by role
Your agency Owns the backlog, the priorities and the client
Tickets in your tracker
Drupal engineers Modules, integrations, migrations
Front end Twig and the theme layer
Lead and QA Part-time, shared across the team
Commits, demos, monthly summary
Your repository Your review gates and your release cadence
Who this is for
- More Drupal work than Drupal people Several projects running at once, a backlog that does not empty, and overflow work your own developers cannot absorb.
- A resignation mid-build The project needs a Drupal engineer next sprint, not after a hiring round.
- A client roadmap measured in months Continuous change requests on a site you run, where a fixed-price project would be renegotiated every month.
- An organisation with its own IT or product team The same arrangement works for a company that runs its own Drupal platform and needs more hands than it can hire. You direct the team the same way, and the rate for each role is on the Rate Card.
What you get: a dedicated Drupal team for agencies
WeebPal is a Drupal company with the surrounding disciplines in-house, so a team is composed by role rather than counted by heads.
- Drupal back-end engineers Custom modules, entity and permission modelling, integrations, migrations.
- Front-end engineers Twig, the theme layer and SCSS, with Vue.js or React where an interface needs it.
- QA engineers Automated coverage with PHPUnit and Playwright, static analysis with PHPCS and PHPStan.
- DevOps engineers Docker and DDEV environments, CI/CD pipelines, deployment and rollback.
- UI/UX designers Where the work needs design rather than the build of one.
- Technical lead or architect Usually part-time across a team.
Around the team, in writing: time reported against tickets, weekly progress against what was committed, and a monthly summary of anything building up as risk.
Sample Monthly team summary March 2026 · example.org backlog
- Tickets closed
- 18
- Hours on tickets
- 462
- Returned in review
- 3
- Open risks
- 2
Committed this month
- Member import from the CRM Merged
- Event listing performance Merged
- Search facets for publications In your review
Team
- Drupal back-end engineers Unchanged
- Front-end engineer Unchanged
- Technical lead, part-time Unchanged
Risks we are watching
- Medium The payment module in use has no Drupal 11 release yet; a replacement is proposed for your decision.
- Low The migration scripts have no reviewer on your side; a walkthrough is suggested.
An engineer reads it and replies within one business day.
How the work runs
How a dedicated team starts
- Discovery Your backlog, your stack, and the hours your team works. You keep the role plan
- Named team Engineers proposed by name and role; you can interview any of them. You approve every name
- Access Your tracker, repository and environments, a walkthrough of the codebase, and your definition of done. You issue every account
- First sprint Real tickets, smaller than usual, chosen so the team touches the parts it will live in. Output reviewed by you
- Monthly review Throughput and fit in writing, with the option to change the composition. You keep the monthly summary
Time zones and overlap
We work from Ho Chi Minh City on Indochina Time, UTC+7. Where a project needs live hours outside our day, they are agreed in the contract as shifted hours for named people, rather than assumed.
| Where your team is | Live overlap | How the work runs |
|---|---|---|
| Australia and New Zealand | Most of the working day | Standups and reviews in normal hours on both sides |
| Europe and the UK | Your morning, our afternoon | Daily live overlap, with nobody working unusual hours |
| North America | None in normal hours | Asynchronous, around a fixed daily handover window; we say before you commit whether your project suits it |
What you can verify
A dedicated team sells people, so the first check is the people: interview the engineers we propose before any of them starts. The rest is public.
- Our code in public WE Mega Menu and Component Builder on drupal.org, with the issue queue that shows how we answer bug reports. More on our open source page.
- Named reviews Agencies that give us Drupal work, among them Ingenuity Solution and Sazae, have reviewed us by name on our reviews page.
- How we work with a client over years After the sprep.org redesign, SPREP handed us a series of further sites built from it. Fagogo, the staff intranet, is one of them.
- A small start The smallest team that covers the backlog, on the minimum term, grown once the fit is proven.
What it costs
A dedicated team is billed monthly, by role. The rate for each role is on the Rate Card on our pricing page, and the monthly figure follows from the roles, the seniority and the term. It is quoted in writing against your backlog before you commit.
Engagements run for a minimum term with a notice period, both agreed at the start. Scaling up needs lead time, so the people you get are the right ones rather than whoever is free; scaling down needs notice, so nobody is dropped mid-sprint.
If what you have is a defined project rather than a capacity gap, a fixed price is usually better value: that is white-label development, or named subcontracting when the bid lists us. Live client sites under your brand are white-label support, an organisation outsourcing a project of its own should read outsource Drupal development, and platforms taken to your own market are on 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
Is a dedicated team the same as staff augmentation?
Yes: named engineers added to your team and directed by you. They stay employed by WeebPal, so the recruiting, the notice periods and the bench stay with us, and you pay a monthly fee by role.
Can we interview the engineers first?
Yes. We expect it for a lead or architect role, and you can ask for it for any role. You are the one who works with them every day.
What happens if an engineer leaves the team?
You are told before it happens, and the change is a handover rather than a substitution: the open tickets and the parts of the system that engineer touched are walked through with the one who takes over.
Can the team appear to our client as our own staff?
If you want. The engineers can work as part of your team under your brand, on the same terms as white-label work, or be introduced as WeebPal. You decide before the first sprint, and the agency terms on this page apply either way.
Who owns what the team writes?
You do, or your client does, from the first commit. The work happens in your repository, and we take no licence over it.
What if it is not working?
The written review at the end of the first month exists for that. The composition can change, a role can be swapped, and the engagement can end on the notice period. A capacity arrangement that is hard to leave stops being capacity.
Not covered here? Ask us directly.
Discuss a dedicated teamAn engineer reads it and replies within one business day.
Tell us about the backlog
Send the stack, the roles you are short of and the hours your team works. We propose named engineers you can interview first.
An engineer reads it and replies within one business day.