The Ecology of How I Work

Most consultancy starts with a brief. The client tells you what they want. You scope it, price it, build it, hand it over. Done.

That isn't how I work.

The projects I take on — the ones I'm proudest of — start with a different kind of conversation. Not "what do you want me to build" but "what are you actually trying to change in the world, and who and what does that change touch?" The build comes later. And when it comes, it's shaped by what the conversation surfaced, not by what the founder thought they needed when they walked in.

I call this ecological scoping. Two lenses, held at once.

The technical lens

This is the obvious one. Every project has a build underneath it — data sources, APIs, architecture, who owns the IP, how the thing keeps running once I'm gone. I'll happily get into the detail of any of that. I work at the MVP level, vibe-coded and fast, and I have a network of senior developers I bring in for bigger builds and project-manage. That's the easy half.

The hard half is everything that sits around the build, and that's where most consultancy quietly fails. A piece of software, a calculator, a tool, a platform — these aren't ends in themselves. They're prosthetics for a story the founder is trying to tell the world. If the story is fuzzy, the tool will be fuzzy too, no matter how clean the code is.

The ecological lens

So before I write a brief, I want to know:

• Who does this transform, and how?
• What do they walk away believing or doing differently?
• What's the narrative arc — the before-state, the encounter with this thing you're building, the after-state?
• What's the brand story underneath all of it? Not the tagline. The worldview.
• And critically: who else is in this ecosystem? Funders, regulators, partner organisations, the user's existing belief systems, the cultural moment this is landing into?

A tool launched into the wrong ecosystem dies, regardless of how good the tool is. A tool launched into the right ecosystem with a clear narrative spine becomes the thing people quote when they're trying to explain what good looks like.

Two examples, two different shapes

This is easier to see through actual projects. In both cases, the challenge wasn't just "build a thing." It was working out the ecology of inputs, data queries, prompts, and defensible outputs — and making all of those components speak to each other.

HABITAT — the Business Habitat Calculator

Dougal Fleming works at the space between business and academia. He's a Biodiversity Finance Fellow at CEEDR, the Centre for Enterprise and Economic Development Research at Middlesex University, and he'd spent years inside the freight and logistics sector watching businesses struggle with the same problem: they knew sustainability mattered, but the tools available were built for corporates with dedicated teams, not for owner-managers running real operations. He wanted to build something that met companies where they actually were — whether they were complete beginners or already certified and restoring.

Dougal brought deep sector knowledge, a clear conviction that restoration of the planet should be business as usual, and an existing carbon calculator he'd already built. HABITAT wasn't starting from scratch — it was building on that calculator and on a previous platform I'd built with CEEDR, funded by NERC (more on that another time). But taking the next step — turning all of that accumulated knowledge into a coherent methodology that could live inside a single platform — required a different kind of architecture. An ecology of inputs, scoring, and outputs that would be both rigorous and usable.

That's where my work sat. Not in the domain expertise — that was Dougal's — but in the architecture underneath it. Through a series of meetings and feedback sessions, I translated his sector knowledge into building blocks: working out what success looked like in the shape of the output, then designing the ecology of the build to get there. What questions to ask, in what order. How to score across ecological domains — air, water, land, soil, noise, light — so that the output wasn't a generic sustainability report but a locally grounded, defensible picture of where this specific business sits inside a living system. How to show what standing still is actually costing you, and what shifts if you act. How to give users the language to prove it — not just to themselves, but to funders, tender panels, supply chain partners.

The governing principle we landed on — there is no neutral score, because in living systems there is only regeneration or atrophy — shaped every design decision. The platform doesn't ask whether you're "good" or "bad." It shows you a direction of travel. Quick wins around avoiding and mitigating environmental impacts build momentum, while the longer pathway weaves biomimicry into operations, processes, and supply chains.

Underneath, the methodology is substantial: a 135-parameter map across ecological and social domains, alignment to key disclosure frameworks, and a scoring architecture that turns qualitative and quantitative inputs into a defensible, locally grounded output. But all of that architecture grew from the scoping conversation, not the other way around. The story arc — a business owner who moves from overwhelm to agency, from defensive compliance to genuine nature-positive positioning — dictated the ecology of the build. The methodology served the narrative. The narrative made the methodology usable.

The VCSE Value Mapper

Different shape entirely. Dr Amy Burnett is a British Academy Policy Innovation Fellow, hosted in the Civil Society and Youth team at the Department for Culture, Media and Sport. She'd developed a multi-dimensional value typology — built inductively from VCSE sector practice — to understand how different kinds of value are, or aren't, being measured and understood within policy and funding frameworks. The problem she'd identified was structural: the systematic invisibility of VCSE contributions. Unlike corporate value mapping tools designed for business model redesign, Amy's typology centred on community-defined value rather than market value capture.

Amy didn't need me to tell her what the problem was. She had the research, a working typology, and her own value consultancy. What she was asking was whether we could build something that animated that research for real-world application — a tool that didn't just measure value, but built capacity in the sector. Something that compounded over time, helping VCSEs articulate their own worth in language that was defensible, fundable, and potentially influential enough to shape policy and public funding.

My job was to animate the research. To take Amy's typology and what she was seeing in practice and translate it into a platform with a story arc: the journey through the questions, the way social and ecological value surface together rather than in separate silos, what the output looks like when a tired CEO reads it at eleven on a Sunday night. The technical build followed the narrative architecture. The methodology — rigorous, grounded in Amy's published work and her policy fellowship — was woven into a tool that served the user rather than testing them.

Two projects. Same approach. Wildly different outputs, because the ecology of each one was different.

The methodology underneath all of it

What connects these projects — and everything I build — is the same underlying challenge. Every platform I design has to solve the same structural problem: how do you create an ecology of inputs, data queries, prompts, and defensible outputs that actually cohere? How do you make a system where the questions lead to scoring that leads to insight that leads to action, and where every piece of that chain is grounded in something real?

My own platform, Keystone Brand Builder, is powered by the same architectural thinking. A microaction taxonomy mapped to habitats, temporal cascades that track impact ecologically and socially, alignment to SDG, TNFD, HACT frameworks. The domain is different — brand intelligence rather than ESG or social value — but the methodology is the same. The ecology of the build is the methodology.

Why most consultancy can't do this

The honest answer is that this approach is uncomfortable to sell. It doesn't fit cleanly into a fixed-price quote because the scoping is most of the value. By the time we know what we're building, the hardest thinking is already done.

It also requires holding two kinds of expertise at once — the technical fluency to actually ship the thing, and the narrative and ecological fluency to know whether what we're shipping is the right thing in the first place. Most consultancies pick one. Strategy houses scope brilliantly and then hand off to a delivery team who didn't sit in the scoping. Build studios ship beautifully and assume someone else has done the thinking. Both halves get done. Neither half gets integrated.

What I'm doing — what I think is genuinely different — is refusing to separate them. The same brain that's asking "who does this transform" is the brain choosing the API, naming the variables, deciding what the empty state should say. The story arc and the technical architecture are drawn at the same desk, in the same week, by the same person.

What this looks like in practice

If you're thinking about working with me, the first thing isn't a quote. It's a conversation. Probably more than one.

We'll talk about the project, of course — what you want to build, what's prompting it, what's blocking it. But we'll also talk about you, your sector, the ecosystem this thing is going to live in, the people it's meant to change, what good would look like in three years if it works.

By the end, you'll either have a much clearer picture of what you actually need to build (which sometimes turns out to be smaller and sharper than you thought), or we'll have decided this isn't the right fit and you'll leave with a better brief to take elsewhere. Both outcomes are useful.

The work itself, when we do it, is faster and more interesting because the hard thinking is done. The story and the system are already speaking to each other.

That's the ecology of how I work.