BounceBuster 2.0: Rust Rewrite, New Site Design

The App You Know, Rebuilt From the Ground Up

BounceBuster started as a Go application (using the Wails framework) with a React/TypeScript frontend. That version shipped for over a year, validated hundreds of thousands of email lists, and did its job. Starting with v2.0, the entire application — the validation engine, the file parsing, the licensing, the UI — has been rewritten from scratch in Rust, with a Dioxus desktop interface replacing the old web-frontend shell. The Go and React code is still in the repository, but only as a reference; it no longer ships.

This wasn't a cosmetic refactor. It's a different language, a different UI framework, and a different internal architecture, released as BounceBuster 2.0 for both Mac and Windows.

Why Rewrite Instead of Maintain?

Three reasons drove the decision:

• Correctness guarantees. A validator is only useful if its verdicts are trustworthy. Rust's type system rules out entire classes of bugs (null pointer errors, data races) at compile time rather than in a user's crash report. For a tool whose entire pitch is "trust the result, don't second-guess it," that matters more than it does for a typical app.
• Concurrency without the footguns. Validating a list means firing off a lot of concurrent DNS/MX lookups without overwhelming resolvers or the network. Rust's async runtime and ownership model make it straightforward to bound that concurrency correctly and know, at compile time, that it's safe.
• A single native binary. The Go version paired a Go backend with a bundled web frontend. The Rust version compiles to one native binary with a native UI layer, which means a smaller install, a simpler build/signing pipeline, and no web-runtime layer sitting between the UI and the validation logic.

None of that is exciting on its own — it's infrastructure work. But it's the kind of work that determines whether a tool stays boring and reliable for the next five years, and reliability is the entire product for something that decides whether your campaign gets sent to a dead address.

Proving It Before Shipping It

The risk in any rewrite is quiet behavior drift: the new engine agrees with the old one on the easy cases and diverges on the edge cases nobody tests. Before any Rust code replaced Go code in production, we built a parity harness that runs both engines against the same corpus of email lists — including deliberately malformed rows, unusual delimiters, and edge-case domains — and diffs the output byte-for-byte. The Rust validation engine, file parser, and CSV export all had to match the Go implementation exactly before they were allowed to ship. If you validated a list with 1.x, 2.0 will call the same addresses valid or invalid, for the same stated reasons.

A Site Redesign to Go With It

The old bouncebuster.app looked like most SaaS landing pages: a blue-gradient hero, a floating screenshot, three emoji feature cards. It didn't look or read like a tool built by people who actually care where your data goes — it just claimed to be private in the same generic copy every competitor uses.

The site has been rebuilt on Next.js's App Router (for proper server rendering and SEO) with a new design system built around the actual argument: your list never leaves your machine, and you pay once instead of per email. That meant:

• Removing vague social-proof stats we couldn't verify, and replacing them with concrete, checkable facts (real pricing tables, a live in-browser email syntax checker, an actual screenshot of the v2.0 app instead of a mockup).
• A distinct visual identity, not another blue-gradient template, so the site reads as something a specific team built rather than something generated.
• Honest comparison pages (see our BounceBuster vs. ZeroBounce breakdown) that name what cloud tools do differently instead of pretending the trade-off doesn't exist.

The goal was the same as the rewrite: fewer things asserted, more things demonstrated.

What Actually Changed for You

If you're a current user, here's the honest summary. Unchanged: the $19 one-time price, the 600-free-per-month tier, the fact that your list is processed entirely on your machine, and the checks BounceBuster runs (format, DNS/MX, and mailbox-level SMTP deliverability). It still does not test or configure SPF, DKIM, DMARC, BIMI, or MTA-STS — those are DNS-level sender-authentication settings, not something a list validator touches; we wrote about what those do and how they fit alongside list hygiene if you're setting them up separately.

Changed: the app is a native Rust binary now, both macOS and Windows installers are code-signed and notarized/verified through an updated release pipeline, and the desktop UI has been rebuilt with a cleaner settings and results layout. The validation logic and its verdicts are unchanged by design — that was the entire point of the parity work.

Try It

If you're still on a 1.x install, the in-app updater will offer 2.0 automatically. If you're new here: download BounceBuster, validate your first 600 addresses free, and see the local-only, one-time-$19 approach for yourself.