In most software, a small labelling mistake is an inconvenience. In email, it can mean a customer waiting for a reply you believe you sent. That is why MailCircle holds one principle above the rest: make "draft" and "sent" impossible to confuse. This article explains why, how it shapes the way we talk about the preview, and what any live version would have to preserve.
The situation: one word on a screen
Imagine a small furniture workshop where the owner drafts a delivery update for a customer late in the evening. The next morning she sees the message in a list, assumes it went out, and gets on with the day. It had not gone out. The customer, waiting at home for a delivery window, calls in frustration by afternoon.
Now imagine the opposite. She believes a message is only a draft, rewrites it and sends it again. The customer receives two slightly different emails and is not sure which time to trust.
Both mistakes come from the same place: an interface that did not make the state of the message unmistakable.
The tension: chat makes everything feel sent
A chat-style view brings a particular risk. In a chat app, the moment you press enter, the message appears in the conversation and, in most cases, has gone. People carry that expectation with them. A chat-native email tool that shows drafts in a conversation view must work against that instinct, not ride on it.
That is a design problem, and it is also a communication problem. How a product is described on its website shapes what people assume when they see the screens.
From the CMO's desk: talking about a preview honestly
MailCircle's marketing perspective treats honesty about the preview as part of the product, not a disclaimer at the bottom. In practice, that means a few habits that run through this website:
- Name the state. We say "concept and interface preview", not "launch" or "available now".
- Show the edge. Every page is meant to show the edge of today: the line between what works now and what is product direction.
- Pair every promise with a limit. "The draft is real. The delivery is not connected." One sentence, both halves.
- Avoid borrowed credibility. No invented customers, testimonials, counts or certifications.
- Separate related technology. The parent Business OS platform has a separate transactional email foundation—for messages such as verification and invitations—which has passed its local integration tests. It is not connected to the chat and draft interface, and we do not use it to suggest that MailCircle sends anything.
The aim is market education rather than persuasion: helping people understand what a chat-native email draft could be, so they can judge it on its real merits.
How the preview applies the principle today
In the current preview, the principle is applied in the simplest possible way: Send is disabled. Everything you write is a draft. Drafts are saved to your browser's local storage, visible in draft lists and in inbox-style views filtered by mine, unassigned and all. Nothing is delivered, so nothing can be mistaken for delivered.
That is the easy case. The real test comes with a live version.
What a live version must preserve
If MailCircle moves beyond the preview, chat-style writing is only worth having if these five things remain solid. They are the conditions, not the features.
1. Recipients, exactly
The to and cc fields must be explicit and visible at the moment of sending. A conversation view must never imply a recipient that is not actually on the email.
2. Threads that match reality
The conversation shown on screen must match the actual email thread the recipient sees. If the chat view groups messages differently from the email thread, people will reply to the wrong context.
3. Durable storage
Today, drafts live only in one browser and are not synced or backed up. Live use needs drafts and history stored durably, available across devices and recoverable.
4. Outbound reconciliation
"Sent" must mean the message actually left and was accepted for delivery, not that a button was pressed. A live version would need to reconcile what was attempted with what went out, and show failures plainly so nobody assumes success.
5. Replies returning
In the preview, replies do not come back into the chat. In a live version they must, in the right conversation, or the chat view stops telling the truth about what was said.
Alongside these sit open questions we will not paper over: mailbox connection to services such as Gmail or Outlook, attachments, and whether recipients would need any particular account. None of these is available or settled today.
The decision behind the principle
It would be easy to make the preview feel more complete: enable a Send button that does something visual, or describe the product as launching. We have chosen not to, because the whole value of email is trust that a message reached the person it was meant for. A tool that blurs draft and sent erodes exactly that trust.
So the order is fixed. First, the writing experience: start with a chat, see the email. Then, only when the five conditions above are met, delivery. Until then, the preview stays a preview, and says so.
What you can do
If you try the preview, look for the state of every message. Ask yourself, on each screen: would I know whether this has gone? If the answer is ever unclear, tell us. That is the most valuable feedback we can receive. You can also read how we approach claims on the trust page and the longer-term direction on the vision page.
