Operations platform
Harbormaster
The back office for my companies: clients, billing, support and the server fleet in one system, with no admin screen. It’s built so Claude does the work through its API and I approve what matters. It launches early in the new year.
What’s inside
Eight modules, one record.
It replaces the billing system, support desk and fleet dashboard WebOps runs on today, one piece at a time. The hosting panel goes last. Each module below is built and tested on a development server, and none has replaced anything yet.
Registry
Clients, services, products and sites in one place, kept for several brands at once.
Billing
Invoices, proration, discounts, overdue reminders and card payments.
Support desk
Tickets by department, with replies that go out only when I approve them. It imports the full ticket history from the old desk.
Fleet control
A fixed catalogue of server operations, the weekly maintenance run, and a load gate that holds work while a server is busy.
Reports
The monthly client report: protection, performance, health, backups and the work done.
Domains
Registrations and renewals, with a ledger that can never renew the same domain twice.
Client portal
Where clients will see Website Health and how their email is being delivered. The health panel moved off client sites and into the portal.
Firewall rules
One signed rule set for every site, fed by what the whole fleet sees. Built, and planned to switch on after cutover.
How work moves
From a ticket to a reply.
The mark is code flag H, the flag a ship flies when it has a pilot on board. The support desk is built around the way I already work with Mahi: Claude does most of the reading and writing, and I make the decisions.
-
It lands
A client opens a ticket or replies to one.
-
Claude reads
It reads the thread, looks into the site or the account, and works out what happened.
-
A draft
Claude writes the reply and stages it. Nothing goes to the client yet.
-
My edits
I read the draft and the findings behind it, decide anything only I can, and send back my edits. Claude redrafts, and we go round as many times as it takes.
-
The send
When the draft says what I want, my approval is the send, so a reply reaches the client only after I’ve read it.
How it changes things
Nothing changes without a plan first.
Why it’s built this way
Every change shows its plan before it writes.
Each capability in Harbormaster works out what it would do before it does anything. A risky step, like issuing invoices or sending a reply, needs my confirmation, and without it the call hands back the plan and writes nothing. The command line, the REST API and the WordPress Abilities API all reach the same operation, so the three can never drift apart. There’s no admin screen to click through: when I need to see something, Mahi will render the view for me.
- Servers run only operations from a fixed catalogue, never a free-form command.
- Every operation can run as a dry run first.
- Each change writes one record of who asked for it and what happened.
- Several brands share one set of mechanics.
Related
What it works with.
Each one has its own write-up.
Website Health audit
It checks every WebOps site every week. Its first read of my own site is why Osita exists.
Mahi
The coordinator that will work Harbormaster’s API, draft the replies and bring me the calls.
Foundry
My WordPress build system. The client portal is built as a Foundry module.
Launching early in the new year.
If you want to talk about how it’s built, write to me.