Geocodio ran on bash scripts, Laravel artisan commands and a homegrown deploy tool for almost a decade as a two-person company. In 2026 they started building full internal applications: mobile-friendly, tested, sharing one component library. Mathias Hansen’s essay names why that only became possible now.

The blocker was never the initial build. You could knock out a useful internal tool in a couple of days even before AI. What killed the bigger ideas was the other side of the coin — keeping them working, up to date, and bug-free, forever. That is the side that got cheaper.

What they run today:

  • Atlas, a customer support platform now rolling out
  • Bullpen, for sprint planning and organisation
  • A deploy tool that shows which release every node is on, with freezes and rollback
  • A compliance tool covering the gaps their commercial platform cannot, pushing results back into it
  • Two open-source tools: Yak (turns Slack/Linear/Sentry/GitHub papercuts into PRs) and Treehouse (a git worktree and docker-compose stack per branch so parallel sessions stop colliding on ports)

The planning-to-implementation ratio is lopsided on purpose. Specs take weeks; implementation takes hours or days. Some of these apps sat in the author’s head for years before the spec existed. The process: heavy upfront planning, research spikes that prove a concept first, repeated “Grill Me” sessions that interrogate a plan until the weak parts fall out, and iterating on UI mockups early because it resolves questions cheaply.

Every tool ships with a documentation subsite — a user guide and internal docs. It is partly AI-drafted, but the consistency is the point, and writing it turns out to do something unexpected: after weeks of specs and plans you lose touch with what you actually built, and the docs bring it back. Each repo’s CLAUDE.md requires that any change touching documentation updates it in the same change, with pages registered in a manifest that owns which pages exist, their order, and their grouping.

Three questions decide what stays off the shelf:

  • Do we have real experience in this domain, or are we learning on the job?
  • What happens to the business if this is down for a day?
  • Does the value come from being integrated with our own data and workflow, or would an off-the-shelf tool do just as well?

Email stays with Bento, comms with Twilio, nobody is writing a Slack. And “just because tools are easier to maintain now does not mean we can take on fifty of them.”

The honesty about trade-offs is the best part. These tools have no staging environment by deliberate choice — for tools only the team uses, a staging environment is one more thing to run and keep in sync. Changes go to production, with local QA, test coverage and CI carrying the weight. A big upgrade to their internal address-data ETL tool then took it down for a day, and the essay says so plainly. Internal tools need uptime too.

Access is the other half: Atlas can see customer accounts and billing, so the tools live entirely inside a private network, unreachable from the public internet — VPN before the sign-in page even loads.

The advice for anyone starting: find the process where you already work around the gap between two tools by hand every week, and build the thing that closes it. No need to believe anyone should rebuild a SaaS product from scratch.