Why we publish a public tech radar

We just published our tech radar. It's a single page that shows every language, framework, platform, tool, and technique we currently use, and where each one sits on a scale from "adopt" to "hold". If you've ever seen the ThoughtWorks radar, it's the same idea, scaled down for a small Wigan agency.

I want to explain why we made one, why it's public, and why you might want to ask your own software supplier for something similar.

What a tech radar actually is

A tech radar is a map of an engineering team's stance on the tools and techniques available to them. Ours has four quadrants by category (Languages and Frameworks, Platforms and Infrastructure, Tools, Techniques) and four concentric rings by stance:

• Adopt: we've used this in production, we're confident in it, we'll recommend it.
• Trial: we're actively using it on real projects and learning the edges.
• Assess: we're prototyping, watching, or experimenting. Not yet trusted in client work.
• Hold: we avoid this for new work. Might be legacy, might be a dead end, might be fine for others but wrong for us.

Each technology sits somewhere on that grid. The further from the centre, the more sceptical we are. The further clockwise, the more it fits a specific category.

That's the whole concept. The value comes from taking a position on every blip and being willing to publish the result.

Why we made ours public

1. It forces honesty

The moment you publish a radar, you cannot hedge. If we say we "do" React, we have to commit: is it Adopt or Trial? If we say we're "exploring" AI, we need to say exactly what we've put into production and what's still a prototype. Writing this down, with a date next to it, is a discipline that sales copy on a services page does not force.

It also kills a certain kind of agency lie. Every agency claims to be "full-stack", "cloud-native", "AI-ready", "mobile-first". Those phrases mean nothing without specifics. A radar turns vague capability claims into a list of named technologies with positions, so technical buyers can check whether the claim actually holds up.

2. It gives clients something real to compare

Most clients choosing a supplier don't know what questions to ask about the stack. They ask "can you build it?" and the answer is always yes. A radar lets a CTO, a procurement lead, or a technical founder scan the list in sixty seconds and get a proper picture:

• Is the agency's default database something I understand and can hire for?
• Do they actually use cloud properly, or just say "cloud" a lot?
• Are they using anything I'd consider risky, and if so, is it trial or adopt?
• Have they ruled out anything I think is important, and what's their reasoning?

That kind of informed decision is much better than a pitch deck.

3. It's useful for us

Publishing the radar is partly for clients, but it's also for us. Running an agency without explicit stack opinions leads to stack drift. Every new project starts with "what did we use last time?" rather than "what's the right thing for this problem?" Over a few years, you end up carrying every tool you ever tried.

Writing the radar forces a quarterly review. Anything in Adopt has to justify itself. Anything in Hold has to either leave the list or have a clear reason to stay. Anything in Trial either graduates to Adopt with evidence, gets dropped back to Assess, or goes to Hold if it didn't work out. That review takes half a day and it stops a lot of bad decisions.

What's on the current edition

The 2026.Q2 edition runs to around 40 blips. Without copying the whole page, the high-level shape:

In the centre (Adopt)

Our default stack for new client SaaS work is unchanged: .NET 9, C#, React 18, TypeScript, Tailwind CSS, Entity Framework Core, Azure SQL, Azure Container Apps, Bicep infrastructure-as-code, GitHub Actions for CI, Postmark for email, Stripe for payments. Flutter for mobile where cross-platform makes sense. Claude Code has moved into Adopt as part of our daily engineering practice.

One ring out (Trial)

HTMX paired with server-rendered ASP.NET MVC on REBLL, a pragmatic alternative to a full React SPA. Azure AI Foundry and Microsoft Semantic Kernel for the agentic AI work we started shipping this year. Cloudflare Pages for the marketing site you're reading right now. Playwright for end-to-end testing as we expand coverage across projects.

Two rings out (Assess)

Things we're watching, not yet betting on client work. Model Context Protocol (MCP) sits here because we think it's going to be the standard way LLMs talk to internal systems, but the tooling is still young.

Outer ring (Hold)

The things we've moved away from. Vue 2 (this site used to run on it), Bootstrap 4, client-only SPAs for content sites, client-side EmailJS for production contact forms, per-client single-tenant deployments. Each of these was a sensible choice once; none of them are our first pick now.

How things move

A blip doesn't jump from Assess to Adopt because someone on the team is excited about it. The rule of thumb is:

• Assess to Trial needs a real project, billable or internal, where we commit to the technology on something a client will use.
• Trial to Adopt needs at least one shipped production build plus a second project where the choice was confident rather than exploratory.
• Anything to Hold needs a reason. Either we've found something better, or the technology has failed us in a specific way we can articulate.

That last point matters. Hold is not a dismissal of a technology in general. It's a statement that, for our clients, our domain, and our scale, something else is a better default. Plenty of things on our Hold list are in use at other agencies, and there's nothing wrong with that.

Why you might ask your own supplier for one

If you're commissioning software, you don't need the full ceremony. You need a short conversation:

1. What's your default stack for a project like ours?
2. What have you moved away from recently, and why?
3. What are you trialling that you haven't shipped yet?
4. What would you refuse to use even if we asked you to?

An agency that can answer those four questions in a paragraph each is an agency with opinions. An agency that can't is an agency that will use whatever happens to be on the developer's machine that week. Either answer is useful, but only the first one is reassuring.

You can also ask to see it written down. A radar is the most compact form, but a one-page architectural principles document serves the same purpose.

What ours is missing

For completeness, a few caveats about our radar:

• It's a snapshot of our stack, not a ranking of technologies in general. A technology on our Hold list might be perfect for a different agency with different clients.
• It doesn't replace deeper conversations about fit for a specific project. We've used technologies outside our radar when the client's existing stack required it.
• Quarterly updates mean it can lag slightly behind reality. If something just landed in production this week, it's going on the next edition, not today.
• The positions are opinions, not certainties. The Assess ring is explicitly about things we're not yet sure about.

With those caveats noted, the radar is still the most honest single artefact we publish about how we actually work.

Try it

Go and browse the radar. Hover over a blip, tap one on mobile, click into a rationale page. If you think we've got something in the wrong ring, tell us. We'd genuinely like to know.

---

Want us to help you commission software well?

We're software developers in Wigan working with businesses across the Northwest and the wider UK. If you'd like technical consultancy, help writing a procurement spec, or a fresh pair of eyes on an existing supplier relationship, get in touch. Transparency about the stack is one small part of how we work.