What Building a Gmail Client for Linux Forces You to Care About
When I started building Spondr, I thought I was building an email client.
That is technically true in the same way that building a house is “just” a carpentry project.
Once you get into it, you realize you are actually building a set of opinions about speed, trust, failure modes, workflow, and how much nonsense users should be forced to tolerate.
That gets especially sharp on Linux.
Linux users are used to tradeoffs. Sometimes too used to them. We learn to tolerate software that is powerful but ugly, flexible but fragile, or technically functional while somehow still being miserable to use every day.
Email is where a lot of that accumulated compromise becomes impossible to ignore.
For me, building Spondr has forced a few beliefs into the open.
1. “Works” and “feels right” are not the same thing
One of the reasons I started this project is that too much Linux desktop software gets graded on effort instead of outcome.
If an app launches, can technically connect to a service, and mostly does the thing on the box, we talk ourselves into calling it good.
But daily-use software is different.
Email is infrastructure. You use it constantly. Small friction compounds. Lag compounds. Weirdness compounds. A reading pane that flashes strangely, a sync button that doesn’t visually confirm what happened, a drag region that works except when you click in the wrong spot — none of those sound important in isolation.
Together, they make software feel cheap.
A lot of product quality is just removing almost-right behavior.
Not glamorous. Still the work.
2. Local-first is not ideology. It’s latency control.
I do not care about “local-first” because it sounds noble.
I care because waiting on the network for basic interaction is a bad desktop experience.
Email clients are especially vulnerable to this because it’s easy to hand-wave the lag away. Search can be remote. Thread loading can be remote. Metadata can be remote. Actions can round-trip and reconcile later. Individually, each compromise sounds survivable.
Collectively, they make the product feel soft.
That is why Spondr keeps a local SQLite cache and local index. Not to cosplay as an offline-first manifesto. To make search feel instant, navigation feel responsive, and the desktop app behave like it lives on your machine instead of renting time from the network.
Gmail is still the system of record. But the desktop experience should start locally whenever it can.
3. Gmail-first beats pretending all email systems are the same
A lot of email software gets vague because it wants to be universally compatible.
I get the impulse. Broad compatibility sounds strategic.
But abstraction has a cost. The more you pretend every email backend behaves the same, the mushier the product gets.
Spondr is Gmail-first on purpose.
That means Gmail search semantics matter. Labels matter. History IDs matter. The sync model matters. Thread behavior matters.
Once you stop pretending all providers are interchangeable, you can make sharper decisions. The architecture gets more specific. The workflow gets more honest. The user experience gets better for the people you are actually serving.
There is a reason narrow products often feel better than broad ones.
They stop lying about what they are.
4. The weird bugs are the product
I used to think of strange edge-case bugs as cleanup work around the “real” product.
Building Spondr has changed that.
The weird bugs are the product.
If Gmail threads flatten into fake single emails, that is not a minor defect. That is the product being wrong.
If optimistic UI updates feel good until the next reload betrays them, that is not polish work. That is the product telling the user one story while the system tells another.
If a white line flashes in the reading pane because a CSS border triggers a WebKitGTK repaint artifact, that sounds absurdly specific. It is also exactly the kind of thing users feel even when they cannot explain it.
Software quality is often buried in details too small to demo well and too visible to ignore once they are wrong.
5. Security decisions are product decisions
If you build an email client long enough, you eventually stop treating security as a separate department.
It changes what you build.
For Spondr, that has meant a few clear lines:
- OAuth through the system browser with PKCE, not embedded webviews
- configuration over arbitrary-code plugins
- sanitizing HTML email before it crosses the boundary into the app
- layering CSP and sandboxing instead of trusting one control and hoping for the best
- moving local storage toward stronger protection because “it’s just a cache” is not a serious answer
Preparing for CASA and a TAC Security audit has been useful partly because it removes the romance from lazy engineering habits.
Raw error bodies in the wrong place stop looking convenient. Loose logging stops looking harmless. “We’ll tighten that up later” starts sounding like what it is.
Security work can be annoying.
It is also clarifying.
6. Linux power users want control, not chaos
One of the strongest product convictions I’ve come out with is that “customizable” is a dangerously slippery word.
A lot of software says customizable when it really means extensible-by-arbitrary-code, which often turns into unstable, insecure, user-maintained craziness.
That is not the kind of control I want Spondr to optimize for.
I think Linux users often want something simpler and more native than that:
- strong defaults
- deep keybinding control
- configuration files
- visual customization
- scriptable external hooks
- software that is composable without becoming a plugin landfill
That is why I keep coming back to configuration over plugin sprawl.
Not because plugins are always bad. Because the tradeoff is often worse than people admit.
7. Native quality is mostly invisible until it isn’t
This might be the biggest one.
When native desktop software is good, people do not talk about it very much. They just keep using it.
The app opens the way it should. Search is fast. Scrolling feels stable. Focus behaves correctly. Window controls work. Dragging works. Keyboard interaction feels natural. State stays coherent.
Nothing is begging for praise.
That is kind of the point.
A lot of the work on Spondr has been about chasing that standard. Not novelty. Just a higher bar for the basic feeling of the thing.
I wanted a Gmail client for Linux that felt first-class instead of tolerated.
Building it has made me more convinced that this bar matters.
Maybe that is the whole project in one sentence.
Linux users do not need more software that merely runs.
They need software that respects the fact that they use it every day.