Show your work.

Acceptance is not delivery

When a sending platform reports 98.7% delivered, it is reporting that a receiving server accepted the connection and took the message. That is a real fact. It is also not the fact you wanted. It says nothing about whether the message reached an inbox, landed in spam, was silently discarded, or sat in a deferral queue for forty minutes while your customer gave up on resetting their password.

The industry has settled on the word “deliverability” to cover all of this, which is convenient precisely because it is vague. We think the vagueness is the product problem. So we separate the terms and use them carefully:

• Acceptance — the receiving server took the message. This is what most dashboards call “delivered”.
• Deferral — the provider asked us to try later, usually with a reason worth reading.
• Inbox placement — where the message actually landed. Measuring this honestly is hard, and we will not claim a number we cannot show our method for.
• Latency — the time between your API call and the provider's answer.

OutSend keeps the provider's raw response on every event. When a message is deferred, you see 450 4.7.1 Not accepted, try again later and which host said it. When it bounces, you see whether it was permanent or transient and why. A summary number is a thing you have to believe. A stored provider response is a thing you can check.

A machine cannot trust “delivered”. It needs evidence it can inspect, explain, and act on.

Your reputation should be yours

Shared sending pools are an elegant piece of economics and a terrible piece of risk management. Your mail goes out alongside strangers, and the worst-behaved sender in the pool sets the ceiling for everyone in it. You will usually find out about this from your own bounce rate, after the damage, with no way to see the cause and no standing to do anything about it.

We score reputation per domain and per workspace. When a sender crosses the line, we stop them — automatically, and before their behaviour becomes your problem. Queued mail on a blocked workspace fails loudly rather than quietly poisoning a shared identity. Your domain authenticates as yours: DKIM, SPF, and DMARC against your own records, in the region you pick.

This costs us money. Isolation is less efficient than pooling, and it means we sometimes turn away volume that would be profitable and reputationally expensive. We think that trade is the point.

Why we will never take venture capital

This is not a grievance. Venture capital is a reasonable instrument for companies that need to buy a market before someone else does. Email infrastructure is not that kind of company. It is the kind where the right answer is usually “be boringly reliable for a decade”, and where the wrong answer is usually whatever produces the steepest chart this quarter.

Taking venture money would install an acquisition clock we cannot turn off. It would make growth the thing we optimise for, and reliability the thing we optimise forwhen there is room. Every infrastructure provider that got worse after a funding round got worse in exactly that order.

Martin Business Consultants built OutSend for its own production sending and then productised it. It is funded by customers paying for cloud hosting and support. That revenue funds the open core indefinitely, and it means our incentives and yours point the same direction: we make money when you keep sending, not when we exit.

Open source is the exit plan

The core is open source, and it runs single-tenant on your own infrastructure. That is not a lead magnet with the useful parts removed — it is the same code, and there is no feature we withheld to sell back to you. Cloud exists because operating mail infrastructure is genuine, tedious work that most teams should not do themselves, not because we made self-hosting artificially painful.

Portability only means something if you can test it. Read the code, run it, export your configuration and your data, and leave if we stop deserving you. A vendor relationship where the exit is documented and supported is a fundamentally different relationship from one where it is theoretical.

What we will publish

Raising the proof burden on everyone else means accepting it ourselves. So we are committing, in public, to publishing things that will sometimes be uncomfortable:

• A recurring transparency report built from anonymised, aggregated production telemetry — with the methodology published before the first set of numbers.
• Incident timelines with scope, cause, remedy, and whether the remedy worked.
• A correction log, because some of what we publish will be wrong and the useful thing is to say so in public.
• Explicit limits and exclusions on every figure, including the ones that make us look worse.

We are starting with the methodology, not the results. Anyone can publish a favourable number; the honest move is to commit to how you will measure before you know what the measurement says.

What this does not mean

A few things we want to be precise about, because overclaiming here would undo the whole point:

• We report the receiving provider's own response per message, per provider. Systematic inbox-placement measurement — where an accepted message landed inside the mailbox — is a different thing, and it will arrive with its methodology attached rather than as a number.
• We have no public SLA yet. When we publish one it will have teeth, and until then we would rather say nothing than imply a guarantee.
• We run millions of emails a day. We name the customers who are happy to be named, and we will not inflate that number or turn regulated mail into a case study.

That list will get shorter. When an item moves, it moves in thechangelog, with the date.

The standard

“Show your work” is not a tagline sitting on top of a feature list. It is the test every product decision has to pass here: can a stranger check this? If a claim cannot be inspected, it does not ship. If a number cannot be reproduced from a published method, we do not print it.

Read the code. Run one trace. Then decide whether we have earned it.

Martin Business Consultants, September 2026.