Why I build small-business backends in Go

Ask ten developers which language to use for a web application’s backend and you will get ten answers. For the small businesses I work with, my answer is Go. That is not because it is fashionable. It is because it directly lowers the cost of owning software.

The cost nobody puts in the quote#

The price of building an application is only the start. Over its life, a business pays for three other things:

1. Hosting, every month, for as long as the app runs
2. Maintenance, meaning security updates, dependency upgrades and the occasional fix
3. Change, every time the business needs the software to do something new

A language choice affects all three. Go happens to be good at all of them.

Hosting: small, fast and frugal#

A Go program compiles to a single, self-contained file. It does not need an interpreter, a virtual machine or a pile of packages installed on the server. It starts in a few milliseconds and uses little memory.

This matters on modern serverless platforms such as Google App Engine and Cloud Run, which can scale an application down when nobody is using it and start it again the moment a request arrives. Slow-starting technology makes that painful because the first visitor waits. Go makes it seamless, so a quiet internal tool or a small customer portal can cost very little to run.

When traffic does arrive, Go handles a lot of it on the smallest instance types. You scale up later, and you scale up less.

Maintenance: fewer moving parts to patch#

Most security problems in web applications come in through dependencies: third-party packages pulled in for everyday jobs. Every one of them has to be watched and updated.

Go’s standard library already covers what most web backends need: an HTTP server, TLS, JSON, cryptography, templates and testing. A typical Go backend needs only a handful of external packages, and Go’s own vulnerability scanner, govulncheck, reports only the issues that affect code your app actually calls. That means less noise and less work.

Change: code that stays readable#

Go is deliberately small and plain. There are few ways to write the same thing, and formatting is automatic and identical everywhere. Code written today reads much like code written five years ago, and much like code written by someone else.

For a small business, that is insurance. If I am not available, or if you hire a developer of your own, they can open the project and understand it. Your software is not held hostage by its original author.

What it looks like in practice#

Here is a handler that accepts a lead from a website form, checks it, stores it in Google Sheets and pings the team:

func (s *Server) SaveLead(w http.ResponseWriter, r *http.Request) {
	lead, err := s.validate(r) // size limits, required fields, email format
	if err != nil {
		s.reject(w, err)
		return
	}
	if err := s.sheets.Append(r.Context(), lead); err != nil {
		s.log.Error("could not store lead", "error", err)
		http.Error(w, "please try again", http.StatusBadGateway)
		return
	}
	s.chat.Notify(r.Context(), lead)
	w.WriteHeader(http.StatusCreated)
}

There is no framework magic. Each step is visible, errors are handled where they happen, and anyone can follow it from top to bottom.

When Go is not the answer#

No tool fits everything. If your business depends on a platform with its own language, such as a particular e-commerce system or CRM, it often makes sense to work within that platform. And for a purely static website, you may not need a backend at all.

For custom web applications, though, meaning portals, booking systems, internal tools and APIs, Go gives a small business what it needs: low running costs, a small security surface and code that will still make sense in ten years.

Thinking about a new application or replacing an old one? Tell me about it.