Eight Mile · 6 case studies
The problem, the build, and what it changed.
6 pieces of work, each told the same way: what was wrong, what we built, and what was true afterwards. Every figure is one the project itself states.
A customer-service agent that decides who should answer before it answers.
Challenge
One assistant answering sales, billing and support questions from the same prompt answers all three badly: the context it needs for a refund is noise when it is quoting a price, and a single system prompt cannot be strict about one without being vague about the others.
Approach
A LangGraph graph with a triage node in front. The LLM classifies every conversation and routes it to a sales, billing or support specialist, each grounded in its own documents through OpenSearch retrieval. Guardrails check the message on the way in and the answer on the way out, and two tiers of caching sit in front of the model so a repeated question never reaches it.
Outcome
Three narrow specialists instead of one wide generalist, in about 2,400 lines of Python on FastAPI. The repository is open source, and the developer half of its page on this site walks the graph node by node.
By the numbers
3
Specialists
2
Cache tiers
FastAPI · LangGraph
Runtime
~2,400 LOC
Size
Repeat questions should never pay for a model call.
Challenge
The same question, worded slightly differently, reaches an LLM hundreds of times a day. An exact-match cache misses almost all of them; a vector-only cache pays for an embedding on every lookup, including the ones a hash would have answered for free.
Approach
Two lookups, and the cheap one goes first. The request is canonicalised and hashed with SHA-256; an exact hit returns without touching an embedding model. Only on a miss is the query embedded and searched by cosine similarity over an HNSW index in pgvector. It is one Postgres table, owned entirely by Alembic, and housekeeping runs on its own thread off the request path.
Outcome
A library of eight files, around 640 lines, that fails open: when the cache is unreachable the call goes to the model as if the cache were not there, so an outage in the cache is never an outage in the product.
By the numbers
2
Lookup paths
Postgres 17 · pgvector
Store
HNSW cosine
Index
~640 LOC
Size
Keep the door moving, even when the network does not.
Challenge
An access reader that asks a server before every decision stops working the moment the venue’s connection does — and a reader that decides alone cannot stop the same card walking through two doors ten metres apart.
Approach
Three layers of decision. A Flutter reader validates campaign cards on the device against a local SQLite copy, so a scan needs no round trip. Nearby readers share what they have just admitted over WebSockets and WebRTC, so a card used at one is refused at the next. And every decision is reconciled with a Spring Boot API that stays the record of identity, campaigns and history.
Outcome
The door works offline without pretending the server no longer matters: nothing is decided that is not later reported. Both halves — the reader and the API — are open source.
By the numbers
3
Decision layers
Flutter 3
Reader
Spring Boot 4
API
WebSockets · WebRTC
Sync
One stable address for a database whose primary can change.
Challenge
A highly available PostgreSQL cluster promotes a replica when the primary fails, and every application pointed at the old primary is now writing to a read-only node. Clients cannot be expected to follow a failover.
Approach
An Ansible role that deploys Spilo/PostgreSQL members, an etcd quorum and a global HAProxy service on Docker Swarm. HAProxy probes each member’s Patroni REST endpoint and sends traffic only to the one returning 200 for /primary, so a promotion changes the route rather than the address. Nothing is published outside the overlay network.
Outcome
Applications connect to one endpoint and never learn which member is primary. Losing quorum removes write authority rather than splitting it, and logical backups are taken through the same primary-aware route.
By the numbers
1
Stable endpoint
Patroni /primary
Health check
none
Published ports
HAProxy 3.0
Runtime
A hosting panel that had no Terraform provider, and no API key to give one.
Challenge
Netcup’s Server Control Panel is driven by hand or by its REST API, and the API has no static key: it authenticates through an OAuth2 device-code login against Keycloak. Servers, VLANs and firewall rules configured by clicking are configuration nobody can review or reproduce.
Approach
A provider written in Go against the SCP REST API. It takes the refresh token from a one-time device-code login, exchanges it for short-lived access tokens on every run, and warns with the new value when the panel rotates it. Eleven resources cover VLANs and their interfaces, firewall policies, reverse DNS, SSH keys, ISO attachments and failover IP routing; sixteen data sources read back servers, disks, snapshots, metrics and tasks.
Outcome
A netcup estate described in HCL, planned and applied like any other. Published on the Terraform Registry, with its sibling provider for velia.net built the same way.
By the numbers
11
Resources
16
Data sources
OAuth2 device code
Auth
Go
Language
Four document tools behind one API, and no file ever stays on the server.
Challenge
Every product eventually needs a PDF invoice, a screenshot of a page, a templated email and a photo squeezed under an upload limit — and every product ends up running its own headless browser to get them, then holding on to the files it made.
Approach
One API in front of Chromium: HTML to PDF, a URL captured as an image, Handlebars templates and image compression that steps quality down until the file fits the byte limit. Every file-producing call returns a signed link rather than the bytes; the link is an HMAC over the artifact and its expiry, so it cannot be pointed at another document or extended. Screenshots refuse private and reserved addresses, including the cloud metadata endpoint, on the URL and on every request the page then makes.
Outcome
After the link expires — an hour by default — the file is deleted and the record kept. API keys are stored as a hash and can render but not administer, so a leaked key costs renders and nothing else. TradeOps itself compresses every upload through it.
By the numbers
4
Render tools
1 hour
Link lifetime
403
Tampered link
Chromium
Renderer
Your problem next
Tell us what is wrong. We will tell you what it would take.
A straight answer about whether we can help, what we would build, and roughly what it would cost.