Go & backend infrastructure
Go backends, in production. Not theoretical.
High-performance Go (Golang) backend development for Tampa Bay startups and SMBs. The same stack we run on SysWard, Threat.gg, MakerCogs, and BarkScan. sqlc, Postgres, Kubernetes — built for scale and observability.
Go is not a hipster language anymore. It runs Cloudflare's edge, Docker, Kubernetes, Hashicorp's stack, half of CockroachDB's customers, and a substantial slice of cloud-native infrastructure. It is fast, the binaries are small, the concurrency model holds up under real load, and the standard library is good enough that you do not need a framework for most things. We have been writing Go in production since 2014.
BlueScripts uses Go as our default backend stack. Three of our four SaaS products (SysWard, Threat.gg, BarkScan) run on Go. We use sqlc for type-safe Postgres queries, the standard library net/http for most servers, and a lightweight set of conventions we have refined over a decade. We know what works and what is hipster bait.
If you are building a backend service that needs to handle real throughput, replacing a Python or Ruby service that has hit performance limits, or integrating Go into an existing polyglot stack — that is the work we do.
What you get
In every engagement
sqlc-generated database access
Type-safe Go from your Postgres schema. No ORM lock-in, no string concatenation, no "what shape is this query result" surprises in production.
Standard library by default
net/http, log/slog, encoding/json, context. We use third-party packages when they earn their keep — not by default. The result is a smaller dependency tree and a stable build.
Real concurrency, not theoretical
Goroutines and channels for the work that benefits from them; sync.Mutex and sync/atomic for the work that does not. We will tell you when concurrency is the wrong answer.
Production observability
OpenTelemetry traces, Prometheus metrics, structured logging via slog. Every Go service ships with the dashboards on day one, not as a Phase 2.
Fast builds, fast tests
Go projects we build typically test in under 10 seconds and build in under 30. Slow tests are a red flag we treat as a bug, not a fact of life.
Migration paths from other stacks
We frequently replace Python, Ruby, or Node services with Go. Strangler fig pattern, dual-running, and clean cutover. No big-bang rewrites.
How we work
Process
Discovery
Architecture review (or design from scratch), performance requirements, integration surface area, and a written plan. Includes a benchmarking plan if you have specific throughput targets.
Design
Service contracts (REST or gRPC), data model, deployment topology. Tradeoffs documented — channels vs queues, sync vs async, monolith vs split services.
Build
Service by service, with integration tests and benchmarks. We run benchmarks in CI so performance regressions are caught before production.
Ship
Production deployment with monitoring, alerting, and runbooks. If we are replacing a legacy service, we dual-run with traffic shadowing before cutover.
Run
On-call retainer for performance tuning, schema evolution, and ongoing feature work. Many Go services need very little ongoing maintenance — that is part of the appeal.
Stack
What we reach for
Core
- Go (latest stable)
- log/slog structured logging
- context propagation everywhere
- errors.Is / errors.As
Database
- PostgreSQL
- sqlc for type-safe queries
- pgx as the driver
- goose / golang-migrate for migrations
API
- net/http
- chi or stdlib mux
- gRPC + protobuf
- OpenAPI generation when needed
Testing
- testing standard library
- testify when convenient
- testcontainers for integration
- benchstat for benchmarks
Infrastructure
- Docker
- Kubernetes
- Terraform
- GitHub Actions
Observability
- OpenTelemetry
- Prometheus
- Grafana + Loki
- Sentry for errors
Pricing
Go service projects vary widely. A focused service replacement is typically 4–12 weeks. A full backend platform build is 12–32 weeks. Contract/retainer Go work for existing teams runs as a weekly engagement. Email a paragraph about the work and we will quote within one business day.
Common questions
FAQ
Do you use a Go web framework like Gin or Echo? +
Usually no. The standard library net/http is good enough for most services, and the chi router fills the gap when stdlib mux gets awkward. We use frameworks when they earn it (rare) and avoid them when they do not (most of the time).
Can you replace our Python or Ruby backend with Go? +
Yes, frequently. Strangler fig pattern: route specific endpoints to a new Go service while the legacy service continues serving the rest. Cut traffic over endpoint by endpoint. We have done this multiple times — never a big-bang rewrite.
What about Go modules and dependencies? +
Minimal dependency tree by default. We pin everything, audit transitive deps quarterly, and prefer the standard library where reasonable. A typical Go service we build has 10–30 direct dependencies, not 300.
Do you do Go testing and benchmarking? +
Yes. Tests run in CI, benchmarks run in CI for performance-sensitive code, and benchstat compares before/after. Slow tests are a bug — we treat sub-10-second package test runs as the norm.
Can you integrate Go into our existing polyglot stack? +
Yes. Go services interoperate cleanly via REST, gRPC, message queues, or shared databases. We pick the integration boundary that minimizes coupling and keeps the migration path open.
Do you offer Go contract / fractional engineering? +
Yes. See our contract software development page. Many of our retainer engagements are with teams that have one or two Go services and need senior Go capacity without hiring full-time.
Other services
Serving the Tampa Bay metro
Have a go development project in mind?
Email us a paragraph about what you're trying to build. We'll respond within one business day.
[email protected]