Blog category
Articles on Architecture from our project work
Everything devs group has written on Architecture, newest first.
Architecture at devs group is not a diagram that disappears into a folder after kickoff. It is the sum of the decisions a system has to carry for ten years: which language, which boundaries, which data model, which way of running it. The articles in this category document how we make those decisions and, at least as importantly, how we write them down so a team can still follow the reasoning two years later.
Architecture
Running MCP servers in Go in production
What the July 2026 MCP specification changes: a stateless core, OAuth instead of a shared token, and the tool design mistakes we see most often.
Architecture
Why we build critical backends in Go
Not because of the benchmarks. Because of what a team can still understand after three years.
Architecture
Decisions you can still understand in two years
Architecture Decision Records are the cheapest tool against systems nobody can explain any more.
What this category covers
Concretely: Architecture Decision Records as the cheapest available defence against systems nobody can explain any more; why we build critical backends in Go; and idempotency as the foundation under every payments API. All three subjects come out of live projects — the broker backend for Relai, the systems we run for the Swiss federal administration — rather than out of textbooks.
If you want to apply the thinking to your own project, the backend and frontend engineering page describes how we build custom software, and in a first conversation we will say plainly which architecture fits your system, including when the honest answer is an unexciting one.
The standard for every article here is the standard we hold our code to: it has to survive being read out of order. Each section answers its own heading in the first sentence, every recommendation names the price it carries, and where a decision depends on context, the context is stated. A reader with three minutes reads the openings and still knows what we recommend and why.
New articles appear when a project forces a decision that generalises. The fastest way not to miss one is the blog's RSS feed, or a look at the blog index every few weeks.
If you are facing a decision like this in your own codebase, it does not have to become a project. An architecture review with a written finding is often a matter of days, and it answers the question that matters: will this system carry the next few years, or is a rebuild due? The backend and frontend engineering page describes the frame; the contact page is the shortest route to a slot.
And because architecture is always an operational decision too, the neighbouring cloud and infrastructure category is worth a look, where the same thinking meets clusters, cost and upgrades.
In the end every architecture is only as good as the reasoning available at the moment the decision was made.