You have an IT or product team of your own, and a Drupal project it cannot staff: a new platform, a rebuild, or a migration that would pull your people off the work only they can do. WeebPal takes the Drupal engineering as an external team. You keep the decisions, the repository and the infrastructure; we build, test, document and hand over to the people who will run it.
Who this is for
- An IT team with no Drupal specialist The platform is Drupal, your team runs everything around it, and hiring a specialist for one project does not pay back.
- A product team with a full roadmap A Drupal build has to happen alongside the product work, without taking your developers off it.
- A rebuild or migration with an end Drupal 7 still running, or a site that has outgrown its build: defined work with a finish line.
- A team that will run the result You intend to maintain the system yourselves afterwards, so the handover has to be real.
If you are an agency delivering to your own client, see white-label development, white-label support or named subcontracting, and the partner programme behind them.
What you get when you outsource to us
- A prototype before any contract A design, a clickable prototype or a working demo on real code, at no charge, so you decide against something real.
- A fixed price against the agreed architecture Scope, integrations and migration are priced in, not discovered later. Changes after it are quoted as changes.
- The repository in your account Custom modules, theme, build tooling and deployment configuration, yours from the first commit, running on your own servers or cloud account.
- Standards your team can keep Drupal coding standards, automated tests, and documentation written for a developer who has never met us.
- Training for the people who will run it Your editors and your developers, before handover.
- A warranty from the team that wrote the code On development work, as set out in the terms below.
Sample Handover checklist Signed off at acceptance
Code
- Repository transferred to your organisation
- Release tag matches production Checked against the live site
- Build and deploy steps documented
Access
- Hosting and DNS accounts in your name
- Our credentials revoked Confirmed in writing
- Admin accounts listed by role
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
Every stage leaves something you keep, which is what makes it possible to stop between stages.
How an outsourced Drupal project runs
- Discovery Goals, users, content and the systems it must talk to, with your team in the room. Output: the discovery notes
- Prototype The hardest part proved on real code, at no charge. Output: the prototype
- Fixed price Quoted against the agreed architecture, not against the brief. You keep the architecture document
- Build Working demos on a staging site each week, in your repository. You keep the repository
- Acceptance Tested against criteria written at the architecture stage, with the current system live until the new one is proven. You keep the test record
- Warranty Defects in what we built are ours to fix. Maintenance afterwards is your choice: your team, us, or someone else. You keep the handover pack
What stays with your team
Outsourcing goes wrong when nobody writes the boundary down. Ours, before the commercial conversation:
- The decisions What the system is for, which trade-off wins when stakeholders disagree, and who signs off. We say what a decision costs in engineering terms and push back when an answer looks expensive for its value, but the call is yours.
- The content What it says, and who approves it. Migrating existing content is ours where it is in scope.
- The systems around it Access to the systems the new one must talk to, and someone who understands them. The integration code and its tests are ours.
- One person who can decide Reachable during the agreed overlap hours, with an hour a week to look at working software. A weekly demo nobody attends turns into a monthly status report.
- The system after launch Run it yourselves, or with a maintenance agreement from us or anyone else. Owning the code is what keeps that choice open.
What to check in a quote, ours included
A day rate says nothing about how many days, who works them, or what you hold at the end. These questions do more of the work, with our answers next to them.
| Question | Our answer |
|---|---|
| What is the price fixed against? | The architecture agreed after the prototype, which you can read |
| Who owns the repository, and from when? | You do, from the first commit rather than on final payment |
| Where does it run? | On your own servers or your own cloud account |
| Are automated tests in scope? | Yes, as part of what ships rather than a line item |
| Who does the work? | Named engineers; you are told before one changes |
| What does the warranty exclude? | New features and third-party API changes; the warranty page lists both sides |
What you can verify
Our direct client work is published under the client's name. SPREP had sprep.org redesigned and rebuilt by us twice, and has since handed us further sites built from it. CreAct, serving enterprises in the UAE and Switzerland, runs a custom web application we built from scratch and still maintain. H&N Corporation in Australia brought its separate service lines into one Drupal site with us, including online visa applications.
Reviews on our reviews page carry the reviewer's name, role and organisation, and a reference call can be arranged: see how we set one up. Our code is public as well: WE Mega Menu and Component Builder on drupal.org, with their issue queues, listed on our open source page.
I've had the pleasure of partnering with WeebPal for the past 5 years. They are a highly reputable international technology company, known for their professionalism, innovation, and consistent delivery of high-quality solutions. Working with WeebPal has been a truly valuable and reliable experience.
What it costs
An outsourced project is priced like any direct project: a fixed price once the architecture is agreed, with the prototype before it at no charge. The project sizes on our pricing page, from Micro to Strategic, show what each size covers, the team it takes and what it needs from you. Secure portals and intranets sit at Extra Large, and platforms serving many units at Multi-Entity.
If your roadmap is continuous rather than a defined project, a fixed price is the wrong instrument: a dedicated team, billed monthly by role, fits better. If what you have is a live site to keep running, that is support and maintenance, which starts with an audit rather than a quote.
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.
- A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
- 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.
Questions we get asked
Is outsourcing cheaper than hiring a Drupal developer?
It depends on how steady your Drupal work is. A hire pays back when there is Drupal work every month; a project pays back when the work has an end. If the work never ends but comes in bursts, a dedicated team billed monthly by role sits between the two.
We already have Drupal developers. Can you still help?
Yes. The useful version is usually the work your team should not be doing: a migration, a specific module, an audit. Adding to a team that exists is a different scope from replacing one, and we scope it that way.
Can your engineers work alongside our developers?
Yes, once the boundary is written down: who reviews whose code, who deploys, and which parts of the system each side owns. Without that, two teams on one codebase spend their time on each other.
Can you build from designs our team already has?
Yes. We build from your designs and point out, before the price is fixed, the states they do not cover yet, such as empty, loading and error screens, so nothing is designed in a hurry during the build.
Can we stop after the prototype?
Yes. The prototype is built before any contract and is not invoiced, so if you do not go ahead, nothing is owed for it. What happens before a contract at each project size is set out on the pricing page.
Not covered here? Ask us directly.
Start a projectAn engineer reads it and replies within one business day.
Build
Related services
- Custom Drupal Development
- Enterprise Website Development
- Custom Web Application Development
- Software Product Development
- Drupal Intranet and Portal Development
- Drupal Website Redesign and Theme Rebuild
- Drupal Multisite and Site Families
- Drupal Commerce Development
- Headless and Decoupled Drupal
- Drupal Module Development and Porting
- UI/UX Design for Web Platforms
- AI Development for Drupal and Web Platforms
Describe the system you need
Tell us what it must do, which systems it talks to and who on your side decides. The prototype comes before any contract.
An engineer reads it and replies within one business day.