Outsource Drupal Development

A senior Drupal team you do not have to recruit, onboard or keep busy between projects, building on Drupal since 2012.

Outsourcing

What you are actually buying

Hiring a Drupal specialist is slow and assumes you can judge one in an interview. Keeping one occupied assumes a steady pipeline of Drupal work. When neither holds, the work goes outside, and the real question is what you are handing over and what happens when it goes wrong. Our answer is the same for every engagement.

  • A team that has done this before

    Not one learning on your project.

  • Price fixed once the architecture is agreed

    A committed price and date, with scope, integrations and migration priced in rather than discovered later.

  • Full source code, yours from day one

    The repository, running on your own servers or cloud account.

  • Warranty from the same team

    One year by default, up to three, fixed by the team that wrote the code.

  • Weekly working demos

    Progress is visible rather than reported.

  • No lock-in

    Standards-compliant code that any Drupal team can continue.

Risks

The honest risks of outsourcing, and what we do about them

  • You cannot see the work

    The usual failure: months of status reports, then a delivery that is not what you meant. We put working software in front of you early and every week after, so scope decisions are made against something running.

  • You cannot leave

    Code you do not own, on infrastructure only the vendor can operate, is leverage. You get the repository from day one and it runs on your own servers or cloud account.

  • Nobody can maintain it afterwards

    Drupal coding standards, automated test coverage and documentation written for a developer who has never met us. Another team can pick it up: that is the test.

  • The price moves

    Discovery is paid and credited on award. After the architecture is agreed the price and date are fixed, with scope, integrations and migration priced in rather than discovered later.

  • Time zones and communication

    We are remote-first and have worked with international clients since 2012. Overlap hours are agreed at the start rather than assumed.

Terms

The contract terms worth reading before you sign

What makes an outsourcing arrangement safe is contractual rather than technical, and worth more than a day rate comparison.

  • Confidentiality

    An NDA is signed before your codebase, your data or your roadmap is shared. That has been the starting position since 2012.

  • Intellectual property

    You own the repository, the custom modules, the theme, the build tooling and the deployment configuration from day one, not on final payment. Drupal core and contributed modules are GPL and stay GPL; nothing we write for you is licensed back to us.

  • Warranty

    Held by you as the party that signs with us: one year by default, up to three, agreed before the project starts and written into the contract. It covers defects, security patches, performance problems and Drupal core minor version compatibility. It does not cover new features or third-party API changes.

  • Non-solicitation

    Mutual, and not implied by the NDA. If you want it, it is written into the contract at signing.

  • Termination

    With the repository already yours, tests and documentation already delivered, and the deployment running in your own account, what you hold the day it ends is everything you need.

Process

How the work is staged

Every stage produces an artefact you keep, which is what makes it possible to stop between any two of them.

    1. Discovery, paid and credited on award

      The entity model, the integration list and the risks, in enough detail that another vendor could quote from it. If you take it elsewhere, it has still done its job.

    2. Architecture

      The content model running against a sample of your real content, and the integration design. Changes here are cheap; the same changes after the build are not.

    3. Fixed price and fixed date

      Quoted against that architecture, not against the brief. Changes after it are quoted as changes.

    1. Build, with weekly working demos

      Progress is something you click, not something you are told. Automated tests and Drupal coding standards are part of what ships.

    2. Acceptance and cutover

      Tested against the acceptance criteria written at architecture stage, and planned so the current system stays available until the new one is proven.

    3. Warranty, then a decision about maintenance

      Warranty runs from the same team. Whether you then want ongoing maintenance from us, from your own team or from somebody else is an open question, and owning the code is what keeps it open.

What outsourcing covers, and what stays with you

Outsourcing goes wrong when nobody wrote down the boundary. So here is ours, before the commercial conversation rather than after it.

What we take The engineering: content architecture, custom modules, the theme, the integrations named in the agreed architecture, automated tests on the code we write, deployment configuration, and the documentation and training that make the result usable without us.

What stays with you The product decisions: what the system is for, which trade-off wins when two stakeholders disagree, what the content actually says, and who signs off. We tell you what a decision costs in engineering terms and we push back when an answer looks expensive for the value, but we do not make those calls on your behalf.

What we need from you One person who can decide, reachable during agreed overlap hours; access to the systems the new one has to talk to, and to somebody who understands them; and an hour a week to look at working software. That last one is not a formality. A weekly demo that nobody attends turns into a monthly status report, and a monthly status report is how outsourced projects end up delivering the wrong thing on time.

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 work, and our answers are next to them.

  • What is the price fixed against? Ours is quoted from the agreed architecture, and you can see it.
  • Who owns the repository, and from when? You do, from day one 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.
  • What does the warranty exclude? New features and third-party API changes; the warranty page sets out both lists in full.
  • Will the named engineers do the work? Yes, and you are told before one changes.
  • Is there public code to read? Our contributed modules are published on drupal.org, and the issue queues show how long fixes actually take.

Our reviews name the reviewers and the projects, and the case studies name the organisations.

When outsourcing is the wrong answer

Saying so early is cheaper for both sides.

If your roadmap is continuous rather than a defined project (a backlog that never empties, priorities that change monthly), a fixed-price project is the wrong instrument and a dedicated team by the month is the right one. If the work has to be delivered to a third party under somebody else's brand, that is white-label development and the confidentiality arrangement is different. And if what you have is a live site that needs keeping alive rather than a project that needs building, that is support and maintenance, which starts with an audit rather than a quote.

If you already have a capable team, the version of outsourcing that usually pays is the work they should not be doing: a migration, a specific module, an audit. Augmenting a team is a different scope from replacing one, and it gets scoped that way.

Questions

Common questions

Do we hire developers, or buy a project?

Either. A fixed-scope project is the usual arrangement and the one where the fixed price and warranty apply. Dedicated capacity alongside your own team also works when the roadmap is yours to set.

What does it cost?

Published engagement bands are on our pricing page: custom development, product-based builds and ongoing maintenance each sit in a different range. The specific number comes from discovery, which is paid and credited if you award the work.

How do we know the code is any good?

Ask for the repository during the build rather than at the end. Automated tests and Drupal coding standards are part of what ships, and our contributed modules on drupal.org are public, with their issue queues.

What if we already have a team?

Then the useful version is usually the work your team should not be doing: a migration, a module, an audit. Augmenting a team that exists is different from replacing one, and we scope it that way.

Are you an agency or a product company?

Both, and it is worth knowing which is talking to you. We build client projects and we maintain production platforms of our own. The platforms are why a build often starts further along than zero.

Other arrangements

Other ways to work with us

See it working before you commit

We build a working prototype first, so you decide against something real.

Start a project
Request a demo