Fun! I was just reading about the star tracker in "Skunk Works: A Personal Memoir of My Years at Lockheed". Really fascinating when you're thinking about how this all happened in the 50's and 60's.

Running the same codebase for 10+ years with a small team is what finally made me fully internalize these rules.

I've always been a KISS/DRY person but over a decade there are plenty of moments where you're tempted to reach for a fancier database or rewrite something in a trendier stack. What's actually kept things running well at scale is boring, known technologies and only optimizing in the places where it actually matters.

We wrote our principles down recently and it basically just reads like Pike's rules in different words: https://www.geocod.io/code-and-coordinates/2025-09-30-develo...

I'm working on Chief [1], a CLI that autonomously works through a PRD using AI coding agents like Claude Code.

You write user stories, start it up, and it loops through them one at a time. Fresh context per story, progress tracked in markdown between iterations. One clean commit per completed story. Has a TUI for watching it work and supports running multiple PRDs in parallel via git worktrees.

Built it because a lot of the "autonomous coding" tooling out there felt overly complex and opaque. Chief is intentionally lightweight and transparent. Everything is just markdown files and git. No magic.

[1] https://github.com/MiniCodeMonkey/chief

We are also 100% customer-funded. AWS makes sense for us for the enterprise version of Geocodio where we are SOC2 audited and HIPAA-compliant.

We are primarily using Hetzner for the self-serve version of Geocodio and have been a very happy customer for decades.

Hahaha. I'll update the post once I hear back from them. One could hope that they might consider an account credit.

That was truly my hope with this post! Glad to hear that

Haha, yep we were lucky to catch this early! It could easily have gotten lost with everything else in the monthly AWS bill.

There's a couple of great open source projects[1][2][3] that try to keep up-to-date lists of domains that belong to disposable email providers.

I would probably not recommend implementing a whitelist for blocking purposes. But perhaps domains on a whitelist could get a slight scoring bump.

[1] https://github.com/disposable-email-domains/disposable-email... [2] https://github.com/disposable/disposable [3] https://github.com/unkn0w/disposable-email-domain-list

As for abuse, I made myself a tool to give myself quintillions of email addresses (not using plus addressing) on gmail.com

I use this to sign up for a service with a unique email that is basically my junk box, but the email is its own unique entry in my password manager

Thanks for giving it a read!

We are mainly B2B so we don't really see signups using Apple's email relay. That said, it could be something we might have to consider blocking in the future if it becomes a problem.

For paying customers, it probably doesn't make a lot of sense to use an anonymous email address, since we ask for your name and billing address either way (have to stay compliant with sales taxes!)