Most expensive Drupal problems are not coding problems. They are decisions — made early, made reasonably, and made without knowing what they would cost two years later.
A content model that made sense for the launch content. A decision to build something custom that a contributed module already did. A choice to solve an editorial problem with a workflow instead of a structural change. None of these look like mistakes at the time. All of them get more expensive to reverse every month.
Consulting is the work of getting those decisions right before they are set, or of untangling them afterwards. This page covers what that involves, when it is worth paying for, and what it cannot do.
What Drupal Consulting Actually Is
It is advice with enough technical depth to be actionable. In practice it takes a few shapes:
- Architecture — deciding how a site should be structured before it is built.
- Assessment — establishing the real state of an existing site, usually before an investment decision.
- A second opinion — reviewing a plan, a proposal or a diagnosis someone else has produced.
- Rescue — working out what to do about a project that has gone wrong.
- Mentoring — raising the capability of a team that will own the work themselves.
What they share is that the deliverable is a decision you can act on, with the reasoning attached — not code.
Is Drupal the Right Choice at All
An honest consultant has to be willing to say no, and the answer is genuinely sometimes no.
Drupal is strong when content is structured and relational, when editorial workflow and permissions are non-trivial, when the same content is needed in several places or formats, when multilingual is a real requirement, and when the site must integrate with other systems. Its cost is complexity: it needs someone who knows it.
It is a poor fit for a brochure site nobody will change, for a single-purpose application with no real content, or for a team with no capacity to maintain it. Choosing Drupal for a five-page site is a decision to pay for capability you will never use — and to keep paying for it at every security release.
Working out which situation you are in is a short conversation, and a considerably cheaper one than finding out after the build.
Architecture Decisions That Are Expensive to Reverse
Some choices are cheap to change later. Others set concrete quickly. The ones worth deliberating over:
- The content model — what your content types are and how they relate. Changing this after content exists means migration.
- Single site or multisite — or several independent sites. This shapes deployment, updates and cost permanently.
- Whether the front end is Drupal or decoupled — a decision that changes the required team, not just the code.
- How editorial workflow works — who drafts, who reviews, who publishes, and whether that is enforced or conventional.
- Multilingual strategy — retrofitting translation is materially harder than planning for it.
The pattern is that each is hard to reverse because content and habits accumulate on top of it. Code can be rewritten in an afternoon; a content model with forty thousand nodes on it cannot.
The Content Model Is the Real Architecture
If there is one place to spend consulting time, it is here.
The recurring mistake is modelling pages instead of things. A content type called "Landing Page" with thirty optional fields, used differently every time, is a page builder wearing a content type's clothes. It cannot be queried usefully, it cannot be reused in another context, and every new requirement adds another optional field.
Modelling the actual things — a Product, an Event, a Person, a Location — with the fields those things genuinely have produces content that can be listed, filtered, related, syndicated and reused. It is more work up front and it is the difference between a site that grows and a site that ossifies.
The useful question when adding a field is not "does this page need this?" but "is this a property of this thing?"
Build, Configure, or Buy
Every requirement can be met by configuring Drupal, installing a contributed module, or writing code. The cost differences are large and not always in the obvious direction.
Configuration is cheapest to build and cheapest to maintain, but can produce structures nobody can explain later — a view with nine relationships and four contextual filters is code, written in an interface, with no comments.
Contributed modules are cheap up front and carry ongoing cost: each one must be updated, tested at upgrades, and replaced if abandoned. Ten modules to avoid forty lines of code is usually a poor trade.
Custom code costs most to write and is the only option that does exactly what you need. It is the right answer when the requirement is genuinely specific to your business, and the wrong answer when it duplicates something the community already maintains.
Reviewing a Proposal Before You Sign It
A common and high-value piece of consulting: reading someone else's proposal before it is accepted.
What is worth checking is rarely the price. It is whether the approach matches the requirement, whether the estimate accounts for the content model and the migration rather than only the visible build, whether it commits to structures that will be hard to change, what happens to the code and the knowledge when the engagement ends, and whether anything in it is undefined in a way that will become a change request later.
A few hours here regularly saves a multiple of itself, and it is a service worth buying from someone who is not bidding for the work.
Second Opinions on Work in Progress
Teams get stuck, and the useful contribution is often not more expertise but a different vantage point.
Typical situations: a performance problem that has resisted several attempts, a bug that keeps returning in different forms, an approach nobody is confident in but nobody can articulate an alternative to, or a disagreement inside the team that has become positional rather than technical.
The recurring pattern in all of these is that a problem which resists repeated fixes is usually being solved at the wrong level. The third patch failing is information: it means the diagnosis is wrong, not that the fix needs more force.
If you are weighing a proposal or a decision like this right now, request a quote for a proposal review and describe what you have been offered.
Rescuing a Project That Has Gone Wrong
Sometimes the situation is not a decision but a mess: the previous developer is gone, the site half-works, and nobody can say what state it is in.
The first job is never to start fixing. It is to establish the facts — what is deployed, what is in version control, whether they match, what is configuration and what is content, what has been changed directly in production, and where the credentials are.
That inventory tells you which of three situations you are in: the work is largely sound and needs finishing; it is salvageable but needs specific parts redone; or the honest answer is to rebuild the site and keep the content. Reaching that judgement quickly is worth a great deal, because continuing to invest in the wrong one of the three is how a bad project becomes an expensive one.
Mentoring an In-House Team
Some organisations do not want a contractor. They want their own team to be better at Drupal, which is a legitimate and often cheaper goal.
That works well as code review with explanation attached, pairing on a difficult piece of work, an architecture session before a build starts, or a defined piece of work done alongside the team rather than instead of it.
The measure of success is that the team needs less help over time. Consulting that makes itself permanently necessary has failed at something.
What Good Consulting Output Looks Like
The deliverable should be written, specific, and usable by someone who was not in the conversation.
A useful document states what was examined and how, gives findings ordered by consequence rather than by ease, makes a clear recommendation instead of listing options without a view, states what remains uncertain and what would resolve it, and gives a first step concrete enough to start on Monday.
The uncertainty section is the part that indicates quality. Any assessment has areas that were not examined deeply enough to be sure about, and saying which is more useful than uniform confidence.
What Consulting Cannot Do
It cannot make a decision that is really about budget, politics, or appetite for risk. Those are the client's, and advice that pretends otherwise is not advice.
It cannot substitute for knowledge of your own business. The consultant knows Drupal; you know your editors, your seasonal patterns, your obligations and what your organisation will actually adopt. The good outcomes come from combining the two, not from one side deferring.
And it cannot make an under-resourced project succeed. If the work needs six months and there are six weeks, no architecture makes that true. Saying so early is more valuable than a plan that assumes otherwise.
Consultant or Developer?
If you know what needs building and need it built, you want a developer — the Drupal developer page covers that work.
You want consulting when the question is what to build, whether to build, why something is not working after several attempts, whether an approach is sound, or what state an inherited site is really in. Those are analysis and judgement, and paying for code before they are answered is how projects get built twice.
The Cost of Deferring a Decision
Architectural decisions get postponed because they are hard and because the current arrangement is working. The cost of that postponement is real but invisible, which is why it rarely enters the conversation.
The mechanism is simple: content accumulates on top of the current model, and habits accumulate around the current workflow. A content model change that would take two days with two hundred nodes takes considerably longer with twenty thousand, because the work is no longer changing the model — it is migrating the content, correcting what does not map cleanly, and retraining people who have built routines around the old shape.
The same applies to integrations. One system reading your content in an undocumented way is a conversation. Six systems doing so is a coordination problem, and you will discover the sixth by breaking it.
This is not an argument for deciding everything up front, which is its own expensive failure. It is an argument for identifying which decisions are the reversible ones and which are not, and spending the deliberation budget on the second category. Most teams spend it evenly, which means the cheap decisions get more attention than they deserve and the expensive ones get made in passing.
A useful question when a decision comes up: if this turns out to be wrong in eighteen months, what will it cost to change? If the answer is "a day", make the call and move on. If it is "a migration", it is worth an afternoon and a second opinion now.
Next Steps
Most consulting engagements start with a short conversation that establishes whether the problem is what it appears to be. Frequently it is not — a "performance problem" turns out to be a content model problem, and a "we need a rebuild" turns out to need three specific fixes.
Practical starting points: an architecture session before a build, a site assessment producing a written report on the state of an existing site, a proposal review before you commit to someone else's plan, or ongoing advisory for a team that wants access to a second opinion as decisions come up.
I have been in web development since 2005 and I am the author of Drupal modules and themes. If you would like to judge the work before a conversation, my drupal.org profile lists them.
You can see examples of past work in the portfolio. To start, request a quote describing the decision you are facing, or get in touch — if it turns out you do not need consulting, that is a perfectly good outcome of the first conversation.