The practice
Three engineers. No bench. No sales team.
We embed together, we ship together, and we leave together. There are no junior consultants on your engagement because there are no junior consultants. The economics are simple: we charge less than a traditional consultancy because we have no bench, no sales team, and no recruiting pipeline to feed. The tradeoff is that we run three or four engagements a year and our calendar is usually booked two quarters out.
Engagement shape
An engagement is eight to sixteen weeks. The first two weeks are assessment: we read your code, run your load tests (or write them), and produce a written architectural review signed by all three of us. At the end of those two weeks either party may walk away with no further obligation.
If we continue, the remainder is implementation. We write code in your repository, under your branch conventions, with your review process. We do not hand you a tarball on the last day. We close out by running the on-call rotation with your team for a final week, so the runbooks get exercised while we are still around to answer questions.
What we do
- Rewrites of hot paths from Ruby, Python, and Node into Go
- Throughput and latency investigations with reproducible benchmarks (p50/p95/p99, explicit sample size, commit-pinned)
- Service decomposition along aggregate roots and bounded contexts
- Queue, scheduler, and ingest pipeline design — with backpressure, not OOM
- Differential testers for behaviour-preserving rewrites
- Observability instrumentation: OpenTelemetry, structured logs, SLO definition, error budgets
- On-call runbooks, incident taxonomy, and postmortem culture
What we decline
- Greenfield products without a proven demand curve
- Frontend work of any kind, including BFFs and GraphQL gateways
- Machine learning infrastructure — we refer to two practices we trust
- Staff augmentation where we would not own outcomes
- Engagements under eight weeks — the math doesn't work
- Rewrites motivated primarily by a resume-driven architect
- Migrations to a specific cloud vendor as the stated goal
The three
M. Halvorsen
Principal · runtime & concurrency
Fifteen years writing systems code, the last nine in Go. Previously built scheduling and queueing infrastructure at two growth-stage companies. Obsessive about pprof output and the word "approximately" in benchmark claims. Owns the scheduler, auth, and ingest engagements; sits out the data-plane work by mutual agreement.
R. Addo-Mensah
Principal · data & storage
Came to Go from a database-internals background. Leads engagements where PostgreSQL, CockroachDB, or Kafka sit on the critical path. Wrote the differential tester used on the ledger rewrite. Has opinions about connection pools, isolation levels, and the true cost of SELECT * that she will share without prompting.
T. Pritchard
Principal · platform & reliability
Spent seven years on infrastructure teams before going independent. Builds the deployment story, the on-call story, and the SLO instrumentation. Writes the runbooks nobody reads until they have to, and then they are glad someone did. Owns the cutover plan on every engagement, including the rollback section people would prefer not to read.
How we structure fees
Assessment (weeks 1–2)
Fixed fee. The deliverable is a written architectural review, a load-test harness, and a go/no-go recommendation. Either party may walk after assessment with no further obligation.
Implementation (weeks 3–16)
Weekly retainer for the three of us as a unit. We do not bill hours and we do not add bodies. Scope changes are negotiated in writing on Fridays — not in Slack on Tuesdays.
Warranty (post-handoff)
For ninety days after handoff we answer questions and fix defects in code we wrote, at no further cost, within a reasonable response window. This is not a support contract; it is a warranty on our work.