About Plimsoll

Ray had eleven sending domains and a sequence that worked for nineteen days. On day twenty the reply rate halved, and by day twenty-four four of the domains were landing in spam for every recipient on Microsoft 365. Nothing in the tooling had said no. It had offered more mailboxes, it had warmed them, and it had let him raise the daily volume the same week two people asked to be removed. The domains were not recoverable and the list had been spent against them.

Plimsoll puts a ceiling on that kind of campaign and reads what comes back to decide how fast a domain may climb. We own the ramp model that sets the climb, the classifier that reads the replies, and the labeled corpus both are fit on, and we run the domains and mailboxes they govern. Nothing here is resold by the unit: mailboxes come with the domain rather than being priced per seat, every domain carries a published daily maximum and a 21-day ramp schedule you can read before you buy, and that maximum is a hard stop the software enforces against the customer rather than a setting the customer can move. There is no button anywhere that raises today's number, support cannot raise it, and an annual contract does not raise it. A company paid for capacity is paid for the volume it ships. We are paid $90 per domain per month whether that domain sends at its ceiling or sits held all week, with no volume tier and no charge for a day spent below the line, which is the only reason a ceiling like this can be enforced at all.

What decides the ceiling is the reply stream, and reading it is the dirty part. Every reply that lands in a Plimsoll mailbox is embedded, all six in six rather than just the residue a model classifies, because the embedding index is what the classifier retrieves against when it runs. Bounces and vacation auto-responders then carry headers a rule can match, and most of the volume is that. Roughly one reply in six is free text with nothing structural to go on: a person writing take me off this in a sentence that also sounds interested, an out-of-office in a language the header does not declare, a forwarded complaint from a security team. Rules cannot separate those, and getting one wrong in the complaint direction is exactly how a domain dies. So the residue goes to a model, which classifies the reply, scores it, and quotes the sentence it decided on. The job is one embedding per reply and one classification per free-text reply across every domain of every customer, inside the same two-hour window every day, plus months of reply history embedded in a single batch each time a new domain is onboarded.

Anything under the confidence floor stops the ramp for that domain and waits for a person, because holding a domain flat for a day costs a customer very little and misreading a complaint costs them the domain. A named reviewer reads the held reply, and the decision recorded is the reviewer's rather than the model's. What accrues from that refusal is ours. Each reviewed reply is written back as a labeled pair, the sentence the classifier quoted alongside the reviewer's decision and score, held detached from customer and recipient identifiers. The pair outlives the message it came from: reply bodies are deleted at 180 days, which is a promise we make our customers and do not intend to stop making, and the pairs are what remain and what the models further down this page are fit on.

The load arrives in two bursts. Onboarding is one. A new customer hands over their domains, we run DNS and authentication checks, build the ramp schedules and backfill months of existing reply history in a single batch with every message of it embedded, which is also what they judge us on before they pay. The daily send window is the other, when every domain across every customer is scored inside the same two hours and the machines are idle either side of it. The sending stack and the mailboxes run on AWS in us-west-2, the reply store, the labeled corpus and the published ramp schedules sit in S3 beside them, and the embedding pass and the queues run on EC2 GPU instances sized for that window and switched off outside it, a bill that grows with every domain we take on. Free-text replies are classified on Azure OpenAI in Microsoft's West US 3 region. Reply bodies are the recipient's own words, and the security reviews our buyers run have started asking where those get read, which is why none of them is read outside the United States.

The dated part of the roadmap is the classifier, because it carries the product: one reply in six is free text no header rule can read, and those are the replies that decide whether a ramp holds. It runs on Azure OpenAI in West US 3 under zero data retention, and no reply body is stored or trained on at Microsoft. Through 2026 and 2027 we fine-tune our own version of it on Azure Machine Learning from the labeled pairs, which makes each call cheaper and each ramp decision better fitted to the mail our customers actually send. Over the same two years the AWS bill grows with the domains we take on: more mailboxes, a larger reply store, more EC2 hours in the send window. Both regions are in the United States, which is the boundary our buyers name as a condition of handing over a domain at all.

There are three of us and we incorporated in Delaware in 2026. Nine customers pay $90 per domain per month, published, with no volume tiers and no annual discount. Nobody has invested and we are paying for this ourselves. The awkward part is the onboarding backfill: it is the largest compute event we run, we charge nothing for it, the first domain runs its whole 21-day ramp free, and all of it has to stay affordable as domains per customer climb.