Go.
Small, fast back-end services that are simple to deploy and straightforward to read.
Talk to us about Go
Key features
What Go does well.
Goroutines and channels
Concurrency is part of the language, so one service can run thousands of lightweight tasks without a thread per request.
Simple cross-compilation
One command builds a binary for Linux, macOS, Windows, x86 or ARM, with no runtime to install on the target.
Compatibility promise
Code written for Go 1 keeps compiling on new releases, so upgrading the toolchain is rarely a large job.
Standard tooling
Formatting, testing, benchmarking, race detection and profiling all ship with the go command.
What we build with it
Plain services that are easy to run.
Go compiles to a single binary with a small footprint and quick start-up, which suits serverless functions and containers. Its standard library covers HTTP, JSON and concurrency well, and the language is small enough that code stays readable across a team.
Serverless APIs
Small services behind an API gateway, each owning a clear part of the domain.
Data processing
Workers that import, clean and validate records in bulk.
Internal tooling services
Command-line tools and services that other systems call reliably.
When it’s the right choice
Go suits back-end services where start-up time, memory use and simple deployment matter, and where the team values explicit, readable code.
When we’d pick something else
When the front end and back end should share types and code, Node.js with TypeScript can be more convenient. For machine learning and data analysis, Python has the wider set of libraries.
Our Go services
How we can help.
New Go services
APIs and workers built for AWS Lambda, containers or plain servers, with tests and structured logging.
Rewrites of hot paths
Moving a slow or memory-hungry part of a Node.js, Python or PHP system into a Go service behind the same API.
Code and concurrency review
Checking error handling, goroutine leaks, data races and context cancellation in an existing Go codebase.
Maintenance and upgrades
Keeping Go versions and modules current, and adding tests where a service has too few to change safely.
How we work
Starting a Go project.
Review what exists
Code, data, hosting and the people who maintain it, before any Go decision is made.
Agree the approach
A written scope: what changes, what stays, the risks and how we will know it worked.
Build in reviewable slices
Working increments your team can test, rather than one large delivery at the end.
Hand over or stay on
Documentation and access for your team, or a defined support scope if you want us to keep going.
In our own products
SoulCare.
SoulCare’s back end is a set of small Go services on AWS Lambda behind API Gateway, with Cognito for sign-in.
Read the case study ↗
Where AI fits
AI in back-end work.
Model calls from your services
Node.js, Go and Python all have official SDKs from the major model providers, so AI steps sit inside your existing services.
AI workflow automation ↗Evaluation pipelines
Python’s data tooling makes it the usual choice for scoring a model against real examples before and after release.
AI evaluation & testing ↗
Where it stops: Retries, timeouts and fallbacks matter more for model calls than for most APIs, and every result that changes a record is validated first.
Where it fits
Related expertise.
- APIs & integrations Connect your product to the systems your team relies on, with clear contracts and handled failures.
- Legacy modernisation Replace or rework an ageing system in stages, keeping the business running while it changes.
- Cloud architecture Choose and structure cloud services around your product’s data, access and operating needs.
Common questions
Go questions.
Is Go hard to hire for?
The language is small and well documented, so experienced developers from other back-end languages can usually become productive in it. We document services and conventions as part of handover.
Can a Go service replace part of an existing system?
Yes. A common approach is to move one bounded area behind a clear API, run it alongside the old system and switch traffic once it is checked.
Further reading
- Firebase, Supabase or a custom back end: how to choose How to choose between Firebase, Supabase and a custom back end by data shape, access rules, cost, exit paths and skills.
- One database per tenant: isolating customer data in SaaS When each customer gets its own PostgreSQL database, and what that means for migrations, connections and running costs.
- MySQL 8.0 has reached end of life: planning the move to 8.4 What MySQL 8.0’s end of life means, and how to plan, test and roll back an upgrade to MySQL 8.4 LTS.
