Most consultancies buy software to run themselves. A skills database here, a knowledge platform there, a stack of subscriptions that almost fit. We went the other way. Over the last few months, we've built two of our own internal tools — a skills matrix and a public handbook — and it's quietly changed how we think about the old buy-versus-build question. Both for ourselves, and for the clients we advise.
Here's the story, and what we took from it.
Two of them, both the kind that sneak up on a growing company.
First: we didn't have a clear, current picture of who can do what. With around 80 consultants across engineering, delivery, product and testing, "who's worked with this client, who holds that certification, who's ready to step up" lived in people's heads. That's fine at 20 people. At 80 it's a genuine constraint — resourcing, training plans and recruitment all get harder when the answer is a Teams message to whoever might know.
Second: the answer to "what's it actually like to work with CDS, and how do you do things?" was scattered across decks, documents and tribal knowledge. Potential clients sizing us up, people thinking about joining, and our own teams all needed the same trustworthy reference — and there wasn't one place to point them.
So, we set out to fix both. A skills matrix where everyone keeps their own skills and client knowledge up to date, and the right people can search across it. And a handbook, published openly, that just explains how we work.
We did look at off-the-shelf options. For both tools, building our own won — and not for the reason you'd expect.
It wasn't really about saving on licence fees, though we are. It was that building got genuinely cheap and fast. With Claude Code doing a lot of the heavy lifting, and Cloudflare's developer platform underneath the skills matrix, we could build something bespoke in days rather than months — and run it for next to nothing.
And when building drops to that cost and speed, the whole calculation changes. The reason "buy unless you really can't" became the default was that building was slow and expensive. Take those two things away and what's left? A tool shaped exactly around how we work, versus one we'd have to bend ourselves around — and the bespoke one is no longer the pricey option. That's worth sitting with, because it's the same shift we help clients think through.
The two tools took deliberately different shapes, because they're solving different problems. We picked the right tool for each rather than forcing both onto one stack — which is, not coincidentally, exactly what we'd advise a client to do.
The handbook is a static website. Content is written in plain Markdown, built into a site with MkDocs, and hosted on Azure Static Web Apps. Every change runs through an automated pipeline that builds the site and — importantly — runs an accessibility check against every single page before it can go live. If a page doesn't meet WCAG AA, it doesn't ship. Accessibility isn't a thing we remember to test later and feel guilty about; it's built into the front door. For a company that cares about the people our clients serve, that felt non-negotiable.
The skills matrix is a different beast: a proper application where people sign in, edit their profiles, and search across everyone. We built it on Cloudflare's developer platform — Workers for the app, with single sign-on through Microsoft Entra ID, so people just log in with their work account and get on with it. Cloudflare was the perfect fit here: quick to build on, secure by default, and on its free tier for something this size, effectively free to run. It isn't the answer to everything — the handbook proves we'll happily reach for Azure when that's the better call — but for a small, secure, internal web app, it was spot on.
We're not done. In fact, we only started the next bit this morning.
The plan is a single "CDS Knowledge Base" — one place that can answer a question by searching across everything we know about how we work, whoever's asking and wherever they ask it. Underneath, that means connecting our tools to AI assistants like Claude through a shared service, so someone can ask a plain-English question and get a grounded answer from the right source, instead of trawling through documents hoping the right one surfaces. It's early days — the first piece went up today — but the direction's set: less searching, more answering.
A few things stuck with me.
Build is back on the table. The instinct to buy made complete sense when building was slow and dear. It isn't anymore. We'd genuinely encourage anyone facing this decision to re-run the numbers with today's costs, not the ones from five years ago.
Pick the tool for the job, not the dogma. A static site and a dynamic app want different things. We used Azure for one and Cloudflare for the other, and both were right. There's a temptation to pick one stack and force everything onto it for the sake of tidiness — resisting that kept each tool simple.
Build the standards in, not on. The handbook can't publish an inaccessible page, because the check sits in the pipeline rather than in someone's good intentions. Good intentions are the first thing to go when a deadline's looming. The quality bar holds best when it's automated and not up for negotiation.
Start small, ship something useful. Both tools did one job well before we added anything else. That's how we're approaching the knowledge base too — get one thing working, prove it's useful, then build out. The alternative, designing the whole thing on paper first, is how you end up with something nobody wanted.
None of this is unique to us, and that's really the point. Be clear about the problem, pick the right tools, keep it simple, and don't let old assumptions make the decision for you. It's exactly what we bring to client work — we just happened to point it at ourselves this time. And we quite enjoyed it.
Take a look at the CDS Handbook to understand our expertise, our ways of working, and the standards we hold ourselves to: CDS Handbook