How we work
Diagnose first. Change one thing. Write it down.
The same four stages on every engagement, whether it is a one-week investigation or an ongoing arrangement. The value is mostly in the discipline, not the cleverness.
- 01
Understand the problem
A conversation and the evidence that goes with it: message headers, DNS records, logs, access to what is failing. No quote before this.
- 02
Investigate and report
We find the cause rather than the first plausible explanation, and write down what we found with the evidence attached — including anything outside our scope.
- 03
Implement what was agreed
Changes in an agreed order, each one reversible, each one verified from outside before the next. You see the diff, not just the invoice.
- 04
Validate and document
Re-test against the original symptom, hand over the runbook and credentials, and say plainly what is fixed and what remains a risk.
The rules we work by
Four habits that come from watching what goes wrong when they are skipped.
One change at a time
The main reason deliverability projects fail is that six things were changed at once and nobody can say which one helped — or which one caused the new problem. Sequential changes take longer on day one and are dramatically faster by week two.
Lower TTLs before touching DNS
A record with a 24-hour TTL takes a day to roll back. We drop the TTL first, make the change, confirm it, then restore the TTL. It costs five minutes and removes the worst failure mode in this work.
Verify from outside
A provider dashboard shows what you intended to publish. A public resolver shows what the world actually sees. Those disagree more often than anyone expects, so verification always happens from outside your own network.
Write it down as we go
Every change is recorded with its old value, new value and the reason. This becomes the handover document rather than something reconstructed from memory at the end.
What we need from you
- A clear description of the symptom and roughly when it started.
- Raw message headers from an affected message, where email is involved.
- Access to the systems being changed — DNS, mail platform, server — requested per system.
- One person who can make decisions, or who can get them made.
- An honest account of what has already been tried.
What you get from us
- A written scope before work starts, naming what is excluded.
- Findings with the evidence attached, not just conclusions.
- A record of every change made, with its previous value.
- A handover document and any credentials, transferred securely.
- A plain statement of what is fixed and what remains a risk.
Working with us, practically
How do engagements usually start?
With a conversation, usually by email or WhatsApp, where you describe the problem. If it is something we can help with, we agree a scoped piece of work — often a diagnostic phase first, because quoting implementation before diagnosis means quoting for a problem nobody has identified yet.
Do you charge for the initial conversation?
No. The first conversation, where we work out whether we are the right people for the problem, is free. Paid work begins once there is a written scope you have agreed to. Discovery on a genuinely undefined problem is paid, time-boxed, and produces a document you own regardless of whether you continue.
How are you paid?
Scoped project work is quoted as a fixed amount against a written scope. Ongoing arrangements are a monthly retainer with a stated inclusion list. We do not bill against an open-ended hourly estimate for work that has not been defined.
What are your working hours?
We agree a response window in writing at the start of the engagement, and we keep to it. Automated monitoring runs continuously and generates alerts at any hour; human response happens within agreed hours. If you need an out-of-hours arrangement, it can be agreed specifically rather than implied.
What if something goes wrong during a change?
Every change has a stated rollback step written down before it is made, which is why we lower TTLs and snapshot servers first. If a change causes a problem, we revert it, say what happened, and work out why before trying again. We do not quietly fix and move on.
What happens at the end?
You receive the documentation, the credentials, and repository access where code was written. Nothing stays hosted on infrastructure you cannot reach, and you are never dependent on us to understand or operate what was delivered.
Ready to describe the problem?
The first conversation costs nothing and usually tells us both whether this is going anywhere.
Get in touch