Articles on Backend from our project work

What this category covers

It opens with running MCP servers in Go in production: what the July 2026 Model Context Protocol specification changes, why a stateless core behind an ordinary load balancer is the more robust choice, and which tool-design mistakes we see most often in the wild. The article came out of the same work with which we connect AI agents to enterprise systems.

The topic is growing. Articles on idempotency in payments APIs and on choosing a language for critical backends sit in the architecture category, because that is where the decision is made before the first line of backend code exists. To see both together, the Go engineering page shows the practice behind them: production systems at the Federal Office of Information Technology, at Relai and at onocoy.

And if you are planning a backend, or inheriting one that grew: we will read it, document the architecture decisions, and say honestly what can stay and what cannot.

What separates a good backend article from a retelling of the documentation is operations. Every text here names the failures that only appear under load, or only after months, and the code we use to avoid them. The examples run, they are built against the current version, and the version number is in the text so it is obvious when an article starts to age.

The category grows with the protocols we actually run in production. After MCP, further subjects from agent infrastructure will follow, because that is where the most interesting backend code in years is being written right now. New articles appear first in the blog's RSS feed.

Behind every article is the same workbench that client projects come off: Go with explicit error paths, PostgreSQL, cleanly versioned interfaces, and a CI/CD pipeline that built every example before it was allowed into the text. If you are planning a backend or hardening an existing one, the Go engineering page lists the services, and a first conversation will give you an honest read on whether you need us for it.

The usual reasons a backend engagement starts with us: an API that becomes unpredictable under load; a payment flow producing double bookings; a monolith whose next feature nobody can estimate any more; or a new product whose core has to be sound from the first day. In all four cases the work starts the same way — read, measure, document, and only then change anything.

The rest is craft, and craft is best shown on the workpiece.

And if you are wondering whether this applies to your team as well: yes, most likely it does.