![Worker using an angle grinder](/sites/default/files/styles/academy_xs_1x/public/images/jannonivergall-worker-5736096.jpg.avif?h=2992ba0a&itok=VNiEwSv-) 2 April, 2026 // 1. [ Back to Home ](/) 2. / 3. [ Back to Resources ](/resources) 4. / 5. [ Back to Blog ](/resources/blog) 6. / # Does your mechanic talk about their tools, or your problems? #Advice #Drupal #Insights ![Daniel Johnson, Developer at Pivale Drupal agency - A man with dark hair and glasses.](/sites/default/files/styles/square_sml_1x/public/2024-02/daniel%20copy.png.avif?h=b044a8f9&itok=RJWjU286) *Written by* Daniel Johnson Backend developer Daniel is a backend developer, with a keen focus on end-to-end testing, attention to detail and crafting bespoke [ecommerce](/solutions/drupal-ecommerce-site-development "Drupal ecommerce") solutions. Daniel is a graduate of [Keele University](https://www.keele.ac.uk/), with a year's study at [VU Amsterdam](https://vu.nl/en), achieving a first class degree in Computer Science. There's a question I find myself coming back to when I think about why some digital projects succeed and others don't, and it has nothing to do with technology. Imagine you take your car to a mechanic. When you describe the problem, a strange noise, something that doesn't feel right, do they launch into an explanation of the tools they use, the diagnostic equipment they've invested in, the particular brand of wrench they prefer? Of course they don't. They listen to what you describe, they ask questions, they get under the bonnet and figure out what's actually wrong. The tools are just how they do the job. The job is your car. Now think about the last time you spoke to a digital agency. How long did it take before they started talking about the technology they use? ## It starts with the problem, not the platform At Pivale we use Drupal a lot. And when I say a lot, I mean it's the direction we end up going on the majority of projects we take on, not because we've decided that Drupal is the answer to everything, but because when you sit down and properly understand what a business actually needs, Drupal tends to earn its place in the conversation on its own merits. We've worked with enough CMS platforms over the years to have a pretty clear picture of the landscape, and we genuinely haven't found anything that comes close to it for the kinds of complex, long-lived, business-critical sites that we tend to build. But the part that I think is actually important is that we don't start there. A satellite control system that a client needed? Not a Drupal project. Simple informational sites where a lightweight static approach makes far more sense than a full CMS? Not Drupal either. We've worked across enough different types of problems to know that the moment you start with a technology and work backwards to fit the brief around it, you're already doing it wrong. The technology should be the answer to a question, not the question itself. So when we do land on Drupal, and we usually do, it's because it genuinely answered what the business needed. Not because it was the thing we were trying to sell. ## A good mechanic diagnoses before they act One of the things that gets quietly glossed over in the agency world is just how much work there is to do before you write a single line of code, or design a single screen. Getting to know a business properly, not just its stated requirements but the way it actually works, the pressures it operates under, the quirks that make it that specific business, is a significant undertaking, and honestly it's where a lot of projects either lay the groundwork for success or quietly sow the seeds of future problems. It's the part of our process that we find clients are often most surprised by, because in their experience with other providers it tends to get compressed, or treated as a box to tick before the "real work" starts. But the discovery phase is the real work. The mechanic who goes straight to replacing parts without a proper diagnosis is the one whose customers come back a month later with the same problem and a lighter wallet. When we talk about getting to know a business, we mean actually getting to know it, the people, the processes, the things that aren't written down anywhere but that everyone who works there just knows. And that knowledge shapes everything that gets built afterwards. ## Not all complexity is necessary, but some of it is Here's something that has come up more than once across projects we've worked on. You start digging into how a business operates, and you find processes that are genuinely complicated. Workflows that involve multiple steps, approvals that pass through several people, systems that talk to each other in ways that aren't immediately obvious. And the instinct can be to treat all of that complexity as a given, something to be accommodated and built around. But not all complexity is necessary. Sometimes you find processes that are complicated because they were built to work around a limitation that no longer applies. A system constraint from five years ago that's long since been resolved, but whose workaround quietly became the way things are done. In those cases, part of what we can offer is a fresh pair of eyes that asks the question nobody inside the business thought to ask, and sometimes the result is that something that looked like a complicated technical requirement turns out to just be a complicated habit. But then there's the other kind of complexity, and this is the kind that deserves real respect. Every business is unique, not in the vague brand-positioning sense of the word, but in genuinely practical ways. The quirks of the systems they use, the particular way their ordering process works, the edge cases that only arise because of the specific combination of things they do. Any off-the-shelf solution is built for a version of your business that doesn't quite exist, because it was built for everyone, and you are not everyone. The idiosyncrasies aren't bugs in your operation, they're often the very things that make it work. We've had projects where an integration requirement looked, on the surface, like unnecessary over-engineering, until we understood why it existed, at which point it became something we had to protect carefully rather than simplify away. Knowing which complexity to untangle and which to honour is one of the more underrated skills in this work. ## Wisdom that arrives before you do Something else that shapes the way we work is the fact that we've been doing this for a fair old while, across a wide range of clients and sectors. And over time, you accumulate a lot of knowledge about what makes a system or website genuinely good, not just functional, but well-structured for SEO, genuinely pleasant for content authors to work with, performant, secure, built on patterns that will still make sense in three years' time. For a long time that knowledge lived in our heads and in our code and in the lessons we'd learned on larger, more complex engagements. And then we decided to actually build it into something. [DayOne Digital](https://www.pivale.co/solutions/day-one-digital) is what we call our starting-point product for Drupal projects, a foundation that arrives already informed by years of working with some demanding clients on some genuinely complex problems. Rather than every new client starting from a blank Drupal installation and effectively paying to rediscover things we already know, DayOne Digital means the baseline is already a long way further along than it would otherwise be. The foundations are solid, the common questions are already answered, and the remaining work can focus on the things that are actually specific to your business. It's what "usually ending up at Drupal" looks like once you've done it enough times to have really learned from it. ## What we actually believe We're going to use the word "manifesto" here and we're aware that's a slightly grand way to put it, but bear with us. We think there's value in being clear about the things that actually guide how we work, rather than leaving it to implication. - **Start with the problem** - Technology is an answer to a question, and the question always comes first. We're not here to sell a platform, we're here to solve a problem, and those two things are genuinely different. - **Simple until it needs to be complex** - There's a version of every project that is more complicated than it needs to be, and that version is almost never better. We push back on unnecessary complexity, but when something genuinely needs to be complex, we don't shy away from that either. - **Earn the right to build** - We don't think it's possible to build something right for a business you don't understand yet. Discovery isn't a preamble to the project, it is the project getting started. - **Real agility, not the performance of it** - Regular check-ins, honest conversations, steering groups that actually steer. We'd rather surface a problem early than present a surprise at the end. - **Respect the weirdness** - Every business has it. The idiosyncrasies, the edge cases, the way things work that doesn't quite fit a standard template. We don't try to iron that out. We build for it. ## How to work with us One of the things we've noticed over the years is that the projects that go really well tend to have something in common on the client side too, and it's worth being honest about what that looks like. The clients who get the most out of working with Pivale are the ones who treat us like part of the team rather than a supplier at arm's length. That means being open about how the business actually works, the messy reality of it, not just the cleaned-up version for the brief. It means being a good internal advocate for the project, someone who can bring the right people into the conversation and help navigate the organisation from the inside. And it means being willing to challenge us, to push back when something doesn't feel right, to ask questions, to tell us when we've missed something. We're not fragile. A client who challenges us is almost always a client whose project ends up better for it. ## Why it works We have a 100% project success rate. That's not something we say lightly, and it's not something we attribute to luck or to a particular piece of technology. It's the result of the approach described in this article, applied consistently, starting with the business, understanding it properly, building something that fits the way it actually works rather than a generic approximation of it, and staying honest throughout the process. The mechanic doesn't fix your car by talking about their tools. They fix it by understanding your problem. That's all we're really doing. ![Daniel Johnson, Developer at Pivale Drupal agency - A man with dark hair and glasses.](/sites/default/files/styles/square_sml_1x/public/2024-02/daniel%20copy.png.avif?h=b044a8f9&itok=RJWjU286) *Written by* Daniel Johnson Backend developer Daniel is a backend developer, with a keen focus on end-to-end testing, attention to detail and crafting bespoke [ecommerce](/solutions/drupal-ecommerce-site-development "Drupal ecommerce") solutions. Daniel is a graduate of [Keele University](https://www.keele.ac.uk/), with a year's study at [VU Amsterdam](https://vu.nl/en), achieving a first class degree in Computer Science. - Facebook Facebook - LinkedIn Linkedin - Threads Threads - X X - Whatsapp Whatsapp - Email Email [ Back to all articles](/resources/blog)