Engineering & infrastructure
Production software, built and operated by THICKRIM.
We build production software, deploy it on infrastructure we configure, and remain responsible for operation after launch. This page documents that work with measured technical evidence.
Software we operate
A business bills through code we wrote.
Garage Bae
The operating system for custom and automotive shops: quotes, work orders, invoices, and payments in one place. We designed it, built it, and run it for Ernie's Custom Shop.
Quotes that carry their own revision history, work orders that survive a parts delay, invoices built off the work that actually happened, and payment that doesn't require the customer at the counter. When an invoice doesn't send, the person who takes that call wrote the code that sends it.
What that requires
- A schema that survives a business changing how it works
- Payments, refunds, and the states in between
- Backups that have been restored, not just taken
- A deploy path that doesn't need a maintenance window
- Someone on call who knows what the code does
Measured, not claimed
One rebuild, in numbers.
Every figure below came off a tool or a repo. There are no percentages on this page we don't measure.
- 164 → 9
- Pages
- 9,102
- Vendor parts removed from the index
- 7 of 9
- Pages shipping zero JavaScript
- 141 ms
- Time to first byte
- One command, no rebuild
- Rollback
- 8 days
- Outage found and closed
Why operating is a job
The site was down for eight days. Every dashboard said it was fine.
A client's site had been serving a 503 to every visitor, and to Googlebot, for eight days.
Everything on the server said it was healthy. The release was published. Maintenance mode was off. The health check answered 200. The container was up.
The domain was the problem: the apex hostname was still an ingress rule on a tunnel we had retired, pointing at an old host serving a two-week-old holding page. Nothing on the live server was in the request path at all, which is exactly why nothing on the live server looked broken.
A monitor that checks the public URL instead of the origin catches that on day one. The reason to hire an operator rather than a builder is that somebody is looking at the right thing.
What we own
Four disciplines, one owner.
Stated as what we take responsibility for, not what we've read about.
The software a business needs when off-the-shelf stops fitting how it works. Operations platforms, dealer and customer portals, quote and intake flows, internal tools that replace the spreadsheet the company is quietly running on.
Getting the systems of record to talk: ERP, CRM, shop management, payments, and the half-documented vendor API somebody has to read the source of. Where a clean API doesn't exist, a middleware layer that does the job without becoming a second thing to maintain.
Hosting, containers, TLS, CI/CD, backups, and monitoring — configured as code and owned by us. Deploys are repeatable, rollbacks are one command, and there is no step in the release that only lives in someone's head.
The part that isn't a project. Patching, dependency updates, certificate renewals, uptime checks, incident response, and a monthly review of what actually happened. The people who wrote it are the people who answer.
The stack
Chosen per project, operated by us.
We're not religious about tools. We are religious about being the ones who can fix them.
& whatever your systems already run onIf your operation already runs on something not pictured, that is a scoping conversation, not a dealbreaker. The integration work is usually the part that decides whether a project takes six weeks or six months, so we scope it before quoting rather than after.
One call to start