Flowmail

Why this project exists

Before Flowmail, I worked with a client on an AI-assisted email client concept walled “Warmest”. The core idea was strong:

• keyboard-friendly email workflows
• fast inbox navigation
• AI summaries and AI-generated reply drafts

At that time I was building frontend for this initiative while the client was running other priorities. As his workload increased, this email project was paused and eventually dropped. The market also shifted quickly as many AI email products appeared.

I later rebuilt the concept in my own way as Flowmail, both to push the product direction further and to deepen my backend experience in Go.

Product direction

Flowmail is built around one principle: users should be able to manage email end-to-end with keyboard only, without losing mouse usability for people who prefer it.

It supports core email workflows (inbox triage, reading, writing, replying, archive/star actions, attachments, search/tabs), but optimized for shortcut-heavy usage.

Architecture choices and tradeoffs

• I kept Electron as the desktop runtime.
• I tested a Tauri version, but for this product shape I did not get enough practical benefit from switching.
• One reason was shortcut behavior and consistency in my existing Electron setup.
• Backend was rebuilt in Go (instead of the earlier FastAPI stack) to improve reliability and gain deeper production-style Go experience.

Key implementation details

• Keyboard-first navigation across inbox and message views.
• A per-page shortcut sheet triggered by ! so users can discover commands in context.
• Rich text compose and reply experience built with TipTap.
• AI-assisted workflow foundation around email summarization and suggested drafts.

Scope and ownership

I built this end-to-end version myself:

• product direction and implementation
• desktop app behavior
• frontend interaction model and shortcuts
• backend service layer in Go

Outcome

• Turned an earlier paused client concept into a working product with clearer UX priorities.
• Validated a keyboard-first email interaction model with full daily-use features.
• Reused and extended knowledge from prior email-client work (including lessons that later helped on Wildhero).

What I learned

• Context matters as much as code: product timing and company priorities can kill good ideas.
• Rebuilding an old concept with clearer constraints is often faster and higher quality than continuing a half-finished direction.
• For productivity apps, shortcut design and interaction consistency are core product features, not UI polish.