Mail is one of the applications I use all day, yet I kept switching between clients that were either too limited, too complicated, or tied to another subscription. Each one came with somebody else's idea of how email should work. Posta grew out of that frustration: a focused mail app shaped around the way I actually use Gmail on my Mac.

Posta is a native macOS mail app for Gmail and Google Workspace accounts. It has a unified inbox, multiple-account support, labels, attachments, rich-text compose, search, keyboard shortcuts, and local notifications. It is deliberately focused. I did not start with a product idea, a business plan, or an attempt to compete with every established mail client. I made Posta for myself. I was its first user, and my own daily needs defined what the app should become.

The Return of Homegrown Software

There was a time when building a personal application meant accepting months of work before it became useful. Even experienced developers had to spend a large amount of time on setup, unfamiliar APIs, repetitive implementation, and the small details that sit between an idea and a reliable everyday tool. That made paying for an existing subscription the practical choice, even when the product did not really fit.

AI has changed that calculation. It has opened an opportunity for homegrown software to return, not as small experiments that are quickly abandoned, but as real applications built around the needs of the person making them.

This does not mean asking AI for an app and accepting whatever it produces. The developer still has to understand the problem, make product decisions, inspect the code, test the behavior, and maintain the result. What AI changes is the amount of friction between those decisions. It helps with unfamiliar framework details, repetitive code, debugging, and exploring alternatives. The feedback loop becomes short enough that a personal tool can grow into something useful.

For developers, this creates a new kind of freedom. We no longer have to assume that every missing feature requires another subscription. If the problem is specific, the scope is sensible, and we are willing to own the result, we can create the application ourselves with exactly the features we need as users.

My Inbox, My Priorities

The starting point was simple: I wanted my own mail app to fit the way I work. My requirements were not unusual, but the combination was personal. I wanted a native Mac app that could bring several Gmail accounts together without hiding which account a message belonged to. I wanted fast keyboard navigation, useful search, proper Gmail labels, and a compose experience that supported formatting, attachments, and signatures.

I also wanted control over the unified inbox. Some accounts should remain available without contributing messages, notifications, or dock badge counts to All Inboxes. That is a small feature, but it has a large effect on how calm and useful the app feels every day. It is also the kind of specific requirement that is easy to prioritize when the developer and the user are the same person.

Posta currently includes:

• Multiple Gmail and Google Workspace accounts
• A unified inbox with account badges and per-account inclusion controls
• Inbox, Sent, Trash, and Starred mailboxes
• Gmail labels and message actions such as archive, trash, read, and star
• Rich-text compose, reply, reply all, and forward
• File attachments and Gmail signatures
• Local and Gmail-powered search across accounts
• Keyboard navigation, background refresh, sounds, and macOS notifications

The app is built with SwiftUI and uses the Gmail API directly. OAuth tokens are stored in the macOS Keychain, while mail metadata and cached message content are kept locally in SQLite. Posta has no analytics and no backend service of its own. The architecture reflects the same goal as the interface: keep the app focused, understandable, and under the user's control.

A Deliberately Narrow Scope

One of the best parts of building your own software is deciding what not to build. Posta does not currently support every mail provider, scheduled sending, or every advanced feature found in a large commercial client. It supports Gmail because that is what I use. It runs on macOS because that is where I need it.

This narrow scope is not a temporary excuse. It is part of the product. A homegrown app does not need to satisfy a market segment, justify a pricing tier, or add features to compete in a comparison table. It only needs to solve the problem it was created for. New features can earn their place through real use instead of being added because another application has them.

That does not make subscriptions unnecessary. Good software takes ongoing work, and many services provide infrastructure, support, collaboration, or expertise that would make little sense to recreate alone. But subscriptions are no longer the automatic answer to every small software need. Developers can make a more useful choice: pay when a service provides real value, and build when the need is personal, focused, and within reach.

A Personal Project for Now

Posta is still the app I made for myself, and for now it remains a personal project. I am continuing to use it every day, refine the experience, and polish the details that only become visible through real use.

I may make Posta public later, once I have finished polishing it and feel it is ready to share. Until then, there is no pressure to turn it into a product or shape it around a broader audience. Its first responsibility is still to work well for me.

Posta is still early-stage software for macOS 14 and newer. It is focused on Gmail and Google Workspace, and its scope will continue to follow real use.

Software That Fits Again

The most interesting opportunity AI creates for developers may not be larger products or faster startups. It may be smaller software that fits one person exceptionally well.

Posta is my example of that. It began with a simple question: if I could shape my mail app around my own habits, what would I keep, what would I remove, and what would I change? AI made the project practical to pursue, but the value comes from answering those questions as both developer and user.

For the first time in a long while, building the tool yourself can be a realistic alternative to adapting your workflow to another subscription. That makes software feel personal again.