I registered the domain at 2am, which is how most good decisions get made in early-stage startups. It had “ship” in it. It had “gate” in it. It described the mechanics accurately, and at 2am, accurate feels like enough.
It isn’t.
For 3 or 4 days I built under that name and talked to people about it. Watched how they responded. And here’s the thing: they understood it. Nobody felt it.
There’s a meaningful difference between those two things. Understanding means your explanation worked. Feeling means the name did the work on its own, without you standing next to it pointing. Shipgate always needed the explanation. Every single time. That’s a problem you want to catch before you’ve got it embroidered on a hoodie.
Then I drew the otter, mostly because a blank landing page is somehow more anxiety-inducing than a failing CI pipeline.
It started as a mascot sketch, something to fill the page. An otter standing at a harbour gate, arms crossed, not letting anything through without a reason. I named him Captain Patch, gave him a coat, and put him at the entrance looking like he’d seen some things and wasn’t impressed by any of them.
I looked at the sketch and thought: that’s the product.
Not a shipping tool. Not a deployment accelerator. A harbour guard. The codebase is the harbour, every pull request is a vessel requesting entry, and Captain Patch audits it before it docks. He doesn’t care how confident the developer sounded in the PR description. He checks anyway.
Shipgate described what happened after approval. autter describes what happens before it. Those are different products with different customers and different reasons to exist.
The name
autter is the auditing otter, and yes, that is the full etymology. No hidden meaning, no recursive acronym, no awkward backstory about a founder who really loved rivers. Just an otter who audits.
Every PR that comes in gets audited at the gate. The verdict is binary: blocked or clear. There’s no such thing as “mostly safe to merge.” Captain Patch either lets you dock or he doesn’t. He’s not rude about it. He’s just thorough, which in this industry is apparently a rare enough quality to build a company around.
The name doesn’t describe the product literally, and I’ve made peace with that. The harbour metaphor handles the description. The name just has to hold the identity. Auditing Otter holds it completely, and the moment I said it out loud I stopped second-guessing. That was a welcome change from the 72 hours prior.
On changing it after 3 days
The GitHub App was registered under Shipgate. A few conversations had already happened under that name. Changing it meant admitting I’d gotten something wrong in the first week, which is a special kind of humbling when you’re also trying to convince people you know what you’re doing.
I almost kept it anyway, which would have been the wrong call dressed up as pragmatism. Getting attached to a bad name to avoid looking indecisive is its own quiet mistake, the kind that compounds slowly and then suddenly all at once, usually around the time you’re explaining it to a journalist and watching their expression.
The early conversations were useful data, as it turned out. People repeated the name back to me with no energy. Nobody said “Shipgate” like it meant anything. That’s the signal. It’s worth listening to before you’ve built a brand, a story, and a mascot around the wrong word. I caught it at three days. Some founders catch it at three years. I’ll take the early version.
Who this is for
Here’s the other thing the name change clarified: who the product is actually for.
Shipgate, as a name, pulled interest from developers optimizing for velocity. Teams that think of code review as a bottleneck to remove, a tax on shipping speed, something to get through rather than something to take seriously. That is a real market with real money in it. It is also not the customer we’re building for.
The customer we’re building for is the person responsible for what gets merged. The open source maintainer with hundreds of contributors they’ve never met, half of whom are now using AI tools to generate pull requests at a pace no human reviewer can match. The engineering lead who’s already been burned once by a migration that looked clean in review and silently corrupted production rows at 3am on a Tuesday. The DevSecOps team that keeps finding security issues after the fact and has run out of patient ways to explain to leadership why the process failed again.
These people aren’t trying to go faster. They’re trying to make sure what ships is actually what they approved, with no quiet surprises hiding in a diff that looked fine at a glance. Tools got faster. Verification didn’t. That gap is where autter lives, and it turns out an otter with a clipboard and strong opinions about merge hygiene is exactly the right guardian for it.
The harbour metaphor is right. The otter is right. The name is right.
The harbour metaphor is right. The otter is right. The name is right. It just took a few days of building under the wrong one to see it clearly, which is honestly a faster feedback loop than most things in this job.
Worth every one of those days.
