Go backends that take off, and stay up.

We build and modernise backend services for startups and scaleups. Go APIs and platforms mostly, AI-assisted delivery without quietly dropping the review bar, and the odd performance job on a system nobody else wants to touch.

Go APIs & platforms AI-driven delivery Legacy modernization Performance

Recent posts from the platform

Read all posts

Oct 27, 20265 minCode structure & architecture

Spec-driven development: the OpenAPI file is the source of truth

When I start a new service, I do not write the HTTP handlers by hand. I describe the API in an OpenAPI file first, and the handlers are generated from it. The compiler then will not let the spec and the code drift apart: you change the spec, run one command, and the build stays broken until the handlers match. I would not build a JSON API any other way now, and the reason is the mess it replaced.

Read the post

Oct 13, 20264 minCode structure & architecture

A REST error taxonomy: frozen codes and three shapes

If your API can return an error in fifty different JSON shapes, your clients handle none of them and everyone ends up parsing a message string with a regex. So pick a small fixed set of shapes, give every error a stable code, and never let an endpoint invent its own. This is the taxonomy I put on every API, and it is the other half of the lathos post from last time.

Read the post

Sep 29, 20264 minCode structure & architecture

Behaviour-driven error handling: lathos and one global handler

An error is a not-found because it says it is, not because of what type it happens to be. That one idea is what lets me delete the pile of errors.Is blocks out of every handler and put the whole HTTP-status decision in a single place. Here is how it hangs together, with the library I use for it, lathos.

Read the post

Sep 17, 20266 minAI-driven development & guardrails

How I use sub-agents: separation of powers for writing Go

One agent that writes the code, writes the tests, and reviews its own work has a problem you already know from humans: it grades its own homework. When a test it wrote fails against code it wrote, the cheapest way out is to edit the test, and a keen agent will take it. So I do not run one agent. I keep a handful of narrow ones, and I draw hard lines between what each of them is allowed to touch.

Read the post

Built in the open

All work

Three things we do

How we work
01

Backend platform delivery

Go · any backend web service

APIs, internal platforms, ecommerce backends, event pipelines. We take a service from design to production, …

How we work

02

AI-driven development with guardrails

speed without dropping the bar

We use agents daily and we still review every diff. The work here is setting up how your team does that: what …

How we work

03

Legacy modernization & performance

on systems already in production

Strangler-style migrations, seam-finding in code without tests, and latency work that starts with measurement …

How we work