Go
Go development for small, busy services
We use Go when a service must handle a lot of concurrent work, stay small to deploy, or sit beside infrastructure. It is a poor default for a typical business CRUD application whose value is the domain screens and whose team hires for C# or TypeScript.
- Concurrent workers
- Lean HTTP services
- File and stream processing
- Operational clarity
What we build
Edge APIs, ingestion workers, and internal tools that process streams of events or files. The standard library and a short dependency list are preferred. The service has one job and a metric that tells you it is doing it.
When Go is a vanity choice
If the hard part is a 40-screen back office and the team is not going to read Go next year, we will not introduce it. A single Go worker beside a .NET or Node.js application is often the honest shape.
Go for small services that stay boring
Go fits
- A narrow network service
- A worker that must be easy to deploy
- A team that wants a small runtime
Go is awkward for
- A rich domain with many rules on day one
- A team that has never operated it
- A screen
What we check before Go
The surface
One service with a clear job. Not a rewrite of the estate.
The operators
Someone has to be willing to read it after the first incident.
The neighbours
Go can sit beside Java or .NET. It does not have to replace them.
Before a Go service
- 01
The surface
One narrow job, written down.
- 02
The deploy
Why a small runtime matters here.
- 03
The readers
Someone willing to learn it for the incident.
- 04
The neighbours
The existing stack it will sit beside.
Marks Go earned the service
- 01
A small boundary
The service does one job and is deployable on its own.
- 02
Concurrency is the reason
It is here because many calls, or a small binary, is the point.
- 03
The binary ships
What runs in production is the build, not a machine that was set up by hand.
- 04
The team can read it
The people who will own it are comfortable changing it.
What we build
Concurrent workers
Queues, backpressure, and a shutdown that finishes or safely retries.
Lean HTTP services
A narrow API with predictable latency and a small deploy.
File and stream processing
High volume intake without dragging in a large framework.
Operational clarity
Logs and metrics that match the one job the service has.
Questions we hear
Do you rewrite existing APIs in Go for speed?
Rarely. We measure first. Most slow business APIs are slow because of queries and chatty integrations, not because the language is Java or Node.js.
Can Go host an AI model?
The orchestration can be Go. The model runtime is usually Python or a vendor API. We do not contort the model stack to share a language with the gateway.
Who maintains it afterwards?
That question decides the engagement. If nobody on your side will own Go, we either train a named person or we do not start.