Does your mechanic talk about their tools, or your problems?

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 wrong. The tools are how they do the job, and 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. We haven’t decided that Drupal is the answer to everything. When you sit down and properly understand what a business 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 know the options well, and we haven’t found anything that comes close to it for the kinds of complex, long-lived, business-critical sites that we tend to build.

The important part, I think, 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 answer a question that comes from the business.

So when we do land on Drupal, and we usually do, it’s because it answered what the business needed.

A good mechanic diagnoses before they act

The agency world tends to gloss over 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, its stated requirements and the way it works day to day, the pressures it operates under, the quirks that make it that specific business, is a big undertaking. It’s where a lot of projects either lay the groundwork for success or 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. We see the discovery phase as 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 the people, the processes, the things that aren’t written down anywhere but that everyone who works there knows. And that knowledge shapes everything that gets built afterwards.

Not all complexity is necessary, but some of it is

This 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 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.

Some of it isn’t needed at all. 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 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 be a complicated habit.

Then there’s the other kind of complexity, the kind that deserves real respect.

Every business is unique in 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. Those idiosyncrasies are often the very things that make your operation 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 good: well-structured for SEO, 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. Then we decided to build it into something.

DayOne 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 complex problems. Rather than every new client starting from a blank Drupal installation and 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 specific to your business.

It’s what “usually ending up at Drupal” looks like once you’ve done it enough times to learn 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 it helps to write down the things that guide how we work.

• Start with the problem: technology is an answer to a question, and the question comes first. We’re here to solve your problem, whichever platform that takes.
• Simple until it needs to be complex: most projects have a version that is more complicated than it needs to be, and that version is rarely better. We push back on unnecessary complexity, but when something 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 is where the project starts.
• Real agility, not the performance of it: regular check-ins, honest conversations and steering groups that steer. We’d rather surface a problem early than present a surprise at the end.
• Respect the weirdness: every business has idiosyncrasies, edge cases and ways of working that don’t fit a standard template. We build for them instead of trying to iron them out.

How to work with us

Over the years we’ve noticed that the projects that go best tend to have something in common on the client side too.

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 works, including the messy reality behind the cleaned-up version in the brief. It means being a good internal advocate for the project, someone who can bring the right people into the conversation and help us find our way around 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 can take it. In our experience, a client who challenges us ends up with a better project.

Why it works

We have a 100% project success rate. We don’t say that lightly, and we don’t put it down to luck or to a particular piece of technology. We put it down to the approach in this article, applied every time: start with the business, understand it properly, build something that fits the way it works, and stay honest throughout.

A good mechanic fixes your car by understanding your problem, and that’s what we try to do too.