Two years ago, when we started prototyping STAMP, we considered forking Mailspring. Mailspring is the open-source descendant of Nylas Mail. It already does multi-account IMAP, has a working UI, has snooze, has decent search. We could have started six months ahead.
We chose to write from scratch. Here is why, in case you were going to ask.
What forking would have given us
- A working IMAP and Gmail/Outlook sync engine.
- An Electron shell, themed and tested.
- A snooze system, a send-later, a unified inbox view.
- A community of users who already trust the binary.
- Roughly six months of build time.
Real value. We did not take this lightly.
What forking would have cost us
- An Electron shell. (Yes, we are listing this twice. It is the heaviest cost.)
- A data model designed for the 2015 inbox, not the 2026 inbox.
- A UI rooted in Apple Mail's flat list metaphor.
- A privacy posture inherited from a different era.
- Code we did not write, that we would have to maintain.
The first three are the killers. We had decided STAMP would be triage-first. Forking a list-first client meant retrofitting triage into a layer it was not designed for. We would have spent the “six months ahead” ripping out assumptions.
The Electron question
Mailspring is an Electron app. Electron means cross-platform, but on macOS it means a Chromium runtime in your dock. RAM, battery, polish, all suffer.
We made an explicit bet: macOS-only, native Swift. Smaller surface area, better polish, much smaller memory footprint. The cost is no Windows or Linux client. We can live with that for now.
Forking Mailspring would have locked us into Electron. Walking that decision back six months later would have been a full rewrite. So we did the rewrite up front.
The data model question
Triage requires structured history. Sender history, follow-up count, sentiment progression, urgency signals. None of this lives natively in IMAP. It has to be derived and stored.
The Mailspring data model stores threads, messages, contacts. It does not store triage signals. Adding them is not a feature; it is a schema migration that touches every read path.
We wanted a clean schema where every thread has triage state from the moment it lands. That is structurally different from a traditional client. Cleaner from scratch.
The privacy posture
We decided early that STAMP would do classification on-device. No email content leaves the user's machine for processing.
Mailspring's sync model goes through a hosted “Sync Engine” in some configurations. This is fine for what they built. It is not fine for what we wanted to build. Inheriting that architecture would have meant spending months tearing it out.
The architecture is the product. You cannot bolt opinions onto a body that disagrees with them.
What we kept from the open-source playbook
We read everyone's code. Mailspring, Postbox, Mail.app interfaces (the public ones), Hey's announced architecture posts, Superhuman's engineering blog when they had one.
We took ideas, not implementation. The undo-send timer, the keyboard shortcut grammar, the snooze-with-context pattern. These are good ideas. They live in our code, written by us.
This is the boring honest answer. Most original software is built this way: standing on the shoulders, but writing the new layer.
What forking is great for
We are not anti-forking. Forking is the right move when:
- You want to ship something close to the original, faster.
- The original's architecture matches your goal.
- You can commit to maintaining the fork.
Mailspring is a viable fork target if you want a slightly different IMAP-first client. It is not a viable fork target if you want a triage-first client. The shape is wrong.
The result
STAMP is about 38,000 lines of Swift today. Roughly 9,000 of those are the triage classifier and tag system. None of it is borrowed code. All of it was written for the 2026 inbox.
The cost was real. We took an extra six to nine months to first user. We ate that cost.
The benefit is also real. Every line in the codebase serves the bet. There is no legacy view in the menu bar that exists because Nylas shipped it in 2014. There is no setting nobody uses. There is no backward compatibility tax.
What this means for users
Probably nothing visible. Users do not care about codebases. They care about the experience.
What they get from this choice: a smaller binary (38 MB), lower memory use, faster cold start, native Mac feel, and a triage layer that was not retrofitted.
What they lose: no Windows or Linux client today. No Electron extensions ecosystem. No instant inheritance of Mailspring's user base.
We made the trade. We stand by it. Two years in, the architecture is still serving the bet.
Where to go from here
If you want the broader category review, best macOS email clients in 2026. If you want to argue with us about the architecture, the email is at the bottom.
A scratch-built, macOS-native email client. hello@stamp.email