How I work
The operating model behind the foundry — and why it's built this way.
Why not just buy another tool
The honest answer is: sometimes you should. If an off-the-shelf solution covers 95% of what you need and the remaining 5% is something you can work around, procurement is the right call.
The problem is that most teams don't find out which category they're in until they're six months into an implementation and the workarounds are starting to look permanent.
I've been on the vendor side, the agency side, and the client side. I've sat in the room where the software gets selected and in the room where it gets blamed for everything two years later. The gap between what a tool promises and what it actually solves for a specific organisation is where most Martech failures live, and it's almost never the tool's fault entirely.
When to build
A custom build makes sense when the requirement is precise rather than exotic. Not “we want something no one has ever built” but “we know exactly what we need and nothing available does it without a significant compromise.”
Build
- The closest off-the-shelf option requires a workaround that creates a new problem
- The data sources you need to connect aren't supported by any standard integration
- The solution needs to behave in a way specific to your operational model
- The vendor designed for the median use case, and you're not the median
Buy
- An existing tool covers 95% of your requirement cleanly
- The remaining 5% can be worked around without compounding cost
- The category is mature and the vendor's roadmap is aligned with yours
- Procurement timelines aren't the bottleneck you're trying to solve
The requirement was mid-process postcode validation against hiring locations, during the form completion, not after. Every standard tool fails that test. The build took three weeks. The alternative was a manual process someone would be running indefinitely.
What the handover model means in practice
Every engagement ends with documentation, a structured walkthrough, and enough time to make sure the team can operate the solution independently. I don't build ongoing support contracts into the model by default, because a solution that requires me to keep the lights on is a solution I didn't build well enough.
If something breaks after handover, I'm reachable. But the goal is always that it doesn't need to.
“If I'm still here in a year, I'm not doing my job well enough.”
How I work with internal teams
I'm not a replacement for internal capability. I'm the person who builds the thing your team doesn't have time to build, using data and infrastructure they already have access to. The best engagements are the ones where I work closely with an internal data or engineering lead who knows the landscape and can take ownership of the output once it's delivered.
Vendor independence
I have no commercial relationships with any technology vendor. No referral fees, no partnership tiers, no preferred platforms. When I recommend a tool, or recommend against one, it's based entirely on whether it fits the problem.
This is unusual enough in the Martech space that some vendors refer clients to me specifically because of it. If you've been burned by advice that turned out to have a commercial interest attached to it, that's a pattern I actively work against.
Questions about the approach?
If you want to understand how this would apply to your specific situation, a short call is the fastest way.
Book a call