Why I'm building Samva

I've been building Samva, an email API and dashboard for product teams. The motivation is fairly straightforward: I want integrating email into a product to be a good experience, including when you're working with a coding agent.

Email is a familiar problem. Products need to send account notifications and updates, and people need a way to reply. There's plenty of room to care about how that work gets done. A clear API, a useful dashboard, and examples that fit the way you build can make a difference to the person doing the integration.

That's the kind of product I want to work on. I enjoy taking something practical and spending time on the details that make it easier to use.

Email in my own projects

I've run into these needs while building my own products. In Icon Maker, for example, support email would get forwarded to my personal inbox, where I'd read it and respond.

It's a small workflow, but it captures something I care about. Email is part of the relationship between a product and the person using it. Sending the message is one step. A reply might contain a question, a problem, or feedback that changes what you build next.

That experience gives me a concrete place to think about the product. I can look at an actual email task and ask what would make it easier to handle. I want Samva to be useful for those everyday jobs, alongside the transactional emails an application sends automatically.

Working with coding agents

Coding agents have become a big part of how I build software. I want that way of working to carry through when I'm adding email to a product.

That's why I care about Samva's SDK, CLI, and MCP server. They give developers and their agents ways to work with email from the tools they're already using. The agent documentation explains how those pieces fit together.

The experience I'm aiming for is concrete. If I'm working on an email template with an agent, I want to be able to inspect the result, ask for a change, and decide when it's ready to send. I want the tools and documentation to make the next step clear.

I also care about examples. A useful integration example helps you get something working in your own application. I see that as part of building the product: making it easier to understand what you can do and how to start.

Getting it into people's hands

I've spent a lot of time building Samva and getting it to a point I'm happy with. I enjoy that work, and it's easy to keep finding another part to improve.

But I want the next improvements to come from people using it. I have ideas about which workflows will matter, and I want to learn where those ideas hold up. Where does someone get stuck? What do they need to look up? Which part saves them time, and which part still feels like work?

Those are questions I want to answer with real use. They will help me decide what deserves more attention.

If you're adding email to a product, take a look at Samva. I'd like to hear what you're building and how the email side of it is going.