Sending is the easy part.
Everything around it is not.
Any tool can put a mail merge behind a mailbox. What decides whether an outbound programme is safe to run is the machinery around the send: knowing who you have already contacted, never writing to an address that will bounce, catching the bounces you do get, threading a reply back to the campaign that caused it, and sending inside hours that make sense where the recipient actually is. This is a build note on the platform we run ourselves, and what is in it.
This platform is our own internal software, not client work. We are showing it because we can open the code and the database, which we cannot do with a client's stack. Deliberately, there are no sending or reply figures anywhere on this page: it is a note about what the software does, not a claim about what our own outbound achieved. Our results work is on the advertising case studies linked at the end.
- Subject
- Our own outbound platform
- Stack
- FastAPI, MongoDB, React
- Scope
- Lead vault to reply inbox
- Live since
- 2026
A mail merge is not
an outbound programme.
Every cold email tool sells the same visible thing: connect a mailbox, import a list, write a template with merge fields, press send. That part is genuinely easy, and it is why the category has forty competitors.
The part that decides whether you can run the programme at all is invisible on a screenshot. Do you know, with certainty, that this person is not on a suppression list from eighteen months ago? Will this address bounce before you find out the hard way and damage the sending domain? When somebody replies, does that reply attach itself to the campaign and the person, or land in a mailbox nobody reads? Is the send window being enforced where the recipient is, or where your server happens to be?
Get those wrong and the failure is silent. Nothing errors. The dashboard stays green, the send count goes up, and the damage - a burned domain, a contact mailed twice, a reply nobody saw - is only visible if you go looking for it. We built for that layer first, and the four things below are all defects we shipped in it and then had to find.
What a sending tool does.
What running outbound needs.
The left column is what the category sells and what a demo shows you. The right is what still has to exist on the day you send to a real list. The gap is where outbound programmes quietly stop working.
The left column gets mail out of the door. The right column is what makes it safe to do again tomorrow.
What is actually
in the box.
Counted from the repository and the live database rather than estimated. Nothing here describes how much mail has gone through it, or what came back.
| Component | Detail |
|---|---|
| Leads in the vault | 664,283 |
| Saved segments | 21 |
| API endpoints | 96 |
| Routers / models / services | 13 / 15 / 35 |
| Database collections | 53 |
| Test files | 55 |
| Backend | ~43,600 lines Python |
| Frontend | ~32,600 lines, 153 files |
The pieces that matter least on a feature list are the largest in the codebase: address verification and bounce handling together are bigger than the campaign builder. That ratio is the whole argument of this page.
Four failures that made no noise
at all.
Each of these is a defect we shipped into our own platform and then had to go and find. They are here because they share a property: nothing errored, nothing alerted, and the damage was only visible to somebody deliberately checking.
The report that took the database down
A campaign screen needs numbers per campaign, and the obvious way to get them is to join the campaign's contacts to the master lead records and count. On a vault this size that join took nearly fourteen seconds and the database was killed for running out of memory partway through - so the page did not merely load slowly, it took the whole service with it.
The related trap is the suppression check. Looking a contact up against the suppression list without scoping the query to the workspace scans millions of rows for every single lead, which is fine on a test list of fifty and fatal on a real one.
The cap that reported success
Adding a segment to a campaign worked. It also stopped at exactly one hundred thousand contacts and said nothing - the operation reported success, the campaign looked correct, and the rest of the segment simply was not there. A limit that fails loudly is an inconvenience; a limit that truncates silently is a campaign you believe you sent.
The same call was also loading the entire result into memory to count it, which pushed the backend past two gigabytes of resident memory on a box shared with several other services.
The encoding bug that reached live subject lines
Imported lead data carried mis-decoded characters - the kind where an apostrophe becomes three symbols. It survived the import, survived the database, and went out in live subject lines, which is the most expensive place for it to appear because that is the one part of the mail a recipient reads before deciding.
It was invisible in the interface for a long time because the browser rendered it in a font where the damage looked like an unusual quote mark.
The send window that was not being enforced
Campaigns carry a sending window so mail arrives during working hours. The window was being evaluated against the campaign's stored timezone, the campaigns were stored in one zone, and the dropdown a person picked from did not offer that zone at all - so a window set for business hours could be enforced several hours away from them.
Nothing about this shows up in a report. The mail goes out, the queue drains normally, and the only symptom is that it arrived at the wrong time of day.
How this was built
This platform was built by a senior developer working with AI assistance throughout, which is why something this wide exists at this size at all. It is worth being plain about the split. AI wrote a great deal of the code. It did not notice that a segment was silently truncating at a round number, or that a send window was being enforced in the wrong timezone, or that mis-decoded characters had reached live subject lines. Every one of the four above was found by a person looking at production output and asking whether it was actually right.
What people ask us
about outbound infrastructure.
What should a cold email setup include beyond sending?
At minimum: a suppression list that covers every contact you have ever mailed rather than the current campaign, address verification that blocks a send instead of merely recording a result, bounce capture from the mailbox itself, replies threaded back to the campaign that caused them, and sending windows evaluated in the recipient's timezone. Ask any vendor to demonstrate those five specifically. They are the ones that are usually absent, and the ones that cost you a sending domain when they are.
Do you need your own platform to run cold email?
No, and most businesses should not build one. The commercial tools handle the sending layer well. We built ours because we needed the lead vault, the scoring and the suppression to sit in the same place as the sending, and because we wanted to be able to answer questions about our own data without exporting it. That is a reason to build; wanting a nicer template editor is not.
Why does address verification need to block the send?
Because a verification result that is only recorded is a report, not a control. If a risky or invalid address can still be sent to, the verification step has changed nothing about your bounce rate, and bounce rate is what determines whether your domain keeps reaching inboxes. The gate has to sit in the sending path and refuse.
What breaks first when an outbound programme goes wrong?
Usually the reply path, and usually silently. If replies are not being attributed back to a campaign - or worse, if the domain you are sending from cannot receive mail at all - then everything downstream of the send is invisible, including the fact that it is not working. Check that a reply to your sending address actually arrives somewhere a person reads, before you check anything about the copy.
To say it plainly once more: the platform described here is our own internal software, not client work, and no sending or reply figures appear on this page. Everything counted above was read off the repository and the live database on 7 September 2026. We are happy to screen-share the platform and walk through any of it on a call.
Check the plumbing before the copy.
Running outbound and not sure the infrastructure underneath it is sound? We will go through the list on this page against your current setup and tell you what is missing, whether or not you work with us.