Email Only Startups: The 2026 Playbook

April 11, 2026

This is a research dossier on startups where email is the only interface. Not "email first". Not "email plus a web dashboard". The strict version: the user sends an email to the product, the product replies, and that is the whole loop. No app to install. No URL to visit. No onboarding screen. Nothing to log into. The address book is the sign up form.

The thesis: this pattern was tried in 2014 through 2020, mostly failed because the AI was not good enough, and is now quietly viable in 2026 because LLMs make parsing trivial, email infrastructure matured, and users are allergic to installing yet another app.

Part 1: The thesis

Every B2B SaaS in 2026 ships a web dashboard. Most ship a web dashboard and a mobile app. A smaller number ship a desktop app too. The dashboard is load bearing: it holds settings, views, state, exports, filters, team management, billing. The assumption is that if you do not have a dashboard, you do not have a product.

The assumption is often wrong. For a narrow but growing class of problems, the entire product surface can be a pair of email addresses: one you send to, one the product replies from. No dashboard. No app. No interface of any kind beyond the user's existing inbox.

Three observations make this class of product worth taking seriously in 2026:

Email is still the only universal interface. Every knowledge worker uses it daily. Every business email address is reachable. Deliverability is a solved problem for transactional messages. No download step, no app store review, no push notification permission prompt.
LLMs made intent parsing trivial. The hardest part of x.ai and Clara Labs in 2016 was understanding what the user meant by "let's grab coffee next week". Claude and GPT 5 solve this in 200 tokens. What used to require a pipeline of NLP, intent classification, entity extraction, and human fallback now fits in a single prompt.
Users are tired of apps. The average knowledge worker has 60+ SaaS tools in their login manager. Installing another one has a real psychic cost. "Just email this address" has zero friction. The product that replaces an app with an email address wins the marginal user.

The punchline: a category that was near dead in 2020 is quietly open again in 2026. The founders who understand the pattern can ship and monetize products that would have required twenty engineers in 2017.

Part 2: Historical case files

x.ai (2014 to 2021)

Founded by Dennis Mortensen. Raised roughly $44M across three rounds. The product: an AI scheduling assistant named Amy (and later Andrew). You CC amy@x.ai on an email thread, Amy parsed the context, replied to coordinate a meeting, and booked it on your calendar. No dashboard for the core loop.

Why it struggled: the AI in 2015 to 2019 was not good enough to handle the long tail. x.ai ended up running a large human operations team behind the scenes to cover parsing failures. Unit economics broke. The company pivoted to a self service scheduling tool with a web interface (same category as Calendly), and was acquired by Bizzabo in 2021.

Lesson: the idea was right, the timing was wrong. In 2026 the human ops team costs nothing because Claude does the parsing reliably.

Clara Labs (2014 to 2020)

Similar pitch to x.ai: email based scheduling assistant. Raised about $13M. Sold to a larger scheduling platform in 2020. Same failure mode: the AI was not ready, the human fallback ate the margin.

Julie Desk (France, 2014 to 2020)

French competitor, same pattern, same fate. Acquired in 2020. Operated with a strong human in the loop for most of its life.

FollowUpThen (2011, still running)

Bootstrapped by Brydon Gilliss. Pure email only. You BCC an address like 3days@followupthen.com and the service emails you back in 3 days with the original thread. Also supports scheduled sends, recurring reminders, and response tracking. No dashboard required; settings happen inside the subject line and body of a special "settings" email. Estimated revenue is in the low seven figures, sustained over 14 years with a tiny team. The clearest proof that pure email only can print money.

Nudgemail (defunct but influential)

Same pattern as FollowUpThen, different syntax. You email tomorrow@nudgemail.com to snooze a message. Simple enough to build in a weekend, still used by thousands at its peak.

Sanebox (2010, still running)

Bootstrapped email filtering tool. Not strictly email only (it has a web config dashboard), but the primary interaction is email based: move a message to a "SaneLater" folder and Sanebox learns from it. Filter training, snooze, reminders all happen by moving messages between folders. Profitable and running for 15+ years.

Hey World (2020 to 2023)

Built by Basecamp as part of HEY. Let users publish blog posts by sending an email to world@hey.com. Pure email authoring, public URL on the other side. Sunsetted in 2023. The loop worked; the business around it did not justify the maintenance for Basecamp.

TinyLetter (2010 to 2024)

Paul Ford's side project, acquired by Mailchimp, shuttered in 2024. Newsletter creation happened through a lightweight web UI but the spirit was email only: one post equals one email, sent to a list. Proved there is demand for the shape of the product but was killed by the parent company.

Meekan, Amy by Ayanda, Felix, Astro

Each tried a variant of the email based assistant pattern between 2015 and 2020. Each either pivoted or shut down. The common thread: AI maturity. The category is literally waiting for the right tooling.

The pattern in the historical record is clear. Email only works when the task is narrow, the reply loop is fast, and the parsing layer is reliable. Before 2023 the parsing layer was the bottleneck. After 2023 it is not.

Part 3: Why 2026 is different

Four things changed in the last 24 months that tilt the economics of email only in the founder's favor.

1. LLMs are the parser

Intent parsing used to be a pipeline: tokenize, classify, extract entities, resolve co references, fall back to a human. Now it is one prompt to Claude Sonnet or GPT 5. The cost per parse is under $0.001. The accuracy is over 95 percent on narrow domains. The development cost is near zero; the ongoing cost scales with usage, not complexity. x.ai's bottleneck is now a 20 line function.

2. Inbound email infrastructure matured

Postmark Inbound, Mailgun Routes, SendGrid Inbound Parse, AWS SES plus Lambda, CloudMailin, ImprovMX, and Resend's upcoming inbound all do the same thing well: receive an email at any address, POST a parsed JSON payload to your webhook, handle attachments, and cost $10 to $50 per month at small scale. Deliverability, SPF, DKIM, and DMARC are configured in minutes, not weeks.

3. Per user aliases are a solved pattern

Generating user.ab12@yourservice.com for every signup is a three line helper. The catchall DNS record takes care of routing. Per user addresses enable authentication without passwords, support threaded state, and make the UX feel personal without any code complexity.

4. Users installed enough apps

The user base is saturated on tools. The path of least resistance for adopting a new workflow is not "install the app". It is "send an email to this address". Pure email only products have a structural advantage in activation rate. Zero percent drop off at the install step because there is no install step.

On top of those four, the cultural shift matters. Chat interfaces (ChatGPT, Claude, Gemini) trained users to type natural language at a system and trust it to understand. Email is the asynchronous version of that same interaction. The user already knows how to "prompt" a product by now.

Part 4: The architectural pattern

Every email only product follows the same underlying shape. Get this right and the rest is easy.

Core loop

User sends an email to a specific address (either a shared command address like add@tasks.app or a per user alias like jane.ab12@tasks.app).
Inbound provider (Postmark, Mailgun, SES, etc.) receives the email and POSTs a JSON payload to your webhook: sender, subject, plaintext body, HTML body, attachments, Message ID, In Reply To.
Your backend identifies the user from the sender address or the alias prefix.
Your backend parses intent. In 2026 this means a single LLM call with the subject and body as input and a structured JSON output.
Your backend performs the action (create a task, save a note, schedule a meeting, run a query).
Your backend sends a reply from the same address, threaded via In Reply To and References headers so the user sees it in the same conversation.

State management

The email thread is the state machine. The Message ID chain tells you which conversation this is. The In Reply To header points to the previous state. You can store conversation state in your database keyed by thread ID (the root Message ID), which lets the user reply to continue a workflow that already exists.

Example: user sends "add a task: prep for Monday call" → backend replies "added, due when?" → user replies "Friday 2pm" → backend updates the task and replies "done". Three emails, one thread, full state captured by the thread's Message ID chain.

Addressing strategies

Shared command addresses. Simpler to build. add@app, remind@app, search@app. The user remembers multiple addresses. Good for small products.
Per user aliases. jane.ab12@app or jane@users.app. Enables auth without passwords. Enables private URLs (each alias is a secret). Requires a catchall MX record and a routing table.
Plus addressing. product+add@app, product+remind@app. One address, multiple verbs. Most providers support it natively.
Subject prefixes. One address, but the subject starts with /add or /remind. Feels like Slack slash commands. Works for power users.

Authentication

The user's email address is the auth token. If jane@acme.com is the sender, it is Jane. Sign up is implicit: first email creates the account. Security depends on the user's inbox being secure, which it has to be anyway because anyone with inbox access can reset passwords on every other service.

Optional hardening: magic link confirmation on first use, DKIM validation on every inbound message, SPF alignment check, and a short cooldown on rapid changes from unknown IPs.

Reply formatting

Reply in plaintext first. HTML is nice but plaintext always works. Put the most important information in the first line. Use the subject line as the headline. Include short commands the user can reply with ("reply DONE to close, reply SNOOZE 2d to push").

Attachments

PDF receipts, screenshots, voice memos, images. All standard parts of the inbound payload from Postmark or SES. The product either stores them, parses them, or both. Accepting attachments is one of the big advantages of email as an interface.

Part 5: The five business models

Model 1: Flat subscription

$5 to $30 per month per user. Works for personal productivity (tasks, notes, reminders, journal). Easy billing via Stripe Customer Portal (the one piece of web that most email only products still need). FollowUpThen and Sanebox both use this model.

Model 2: Credits or per action pricing

$0.10 to $2.00 per email processed for high value actions like AI research, transcript summarization, or document generation. Matches the underlying LLM cost and scales naturally. Ideal for AI powered products.

Model 3: Freemium with usage caps

First 20 emails per month are free; $10/month unlocks unlimited. Low friction trial (just send an email), clear upgrade path once the user is hooked. Works especially well when the product is asynchronous enough that the free tier serves as viral loop.

Model 4: Team plans

$5 to $10 per seat per month. The team shares a set of command addresses or a per team alias. Good for team standups, shared CRM, shared to do lists. Billing is still email based (monthly usage summary emailed to the team owner) with a Stripe portal for payment method.

Model 5: B2B white label

License the email only infrastructure to larger companies that want to add email interactions to their own product without building the plumbing. You run the inbound webhooks, the LLM parsing, and the reply composer; they brand it as their own. Like Twilio but for email interactions. Recurring contract revenue, higher unit economics.

Most email only products start with Model 1 or Model 3. Model 2 is the native fit for AI heavy products. Model 5 is where a successful infrastructure company eventually lives.

Part 6: 40 email only startup ideas

Each idea below can be built with the same underlying stack: inbound webhook, LLM parser, database, outbound reply. The differentiator is the parse and the vertical.

Productivity and PIM

1. Email only task manager

Send any email to add@todo.email and it becomes a task. Forward a message to file it as a task referencing the original. Reply DONE to close. Reply SNOOZE 2d to push. Daily digest arrives every morning with your open items. That is the entire product. $8/month. Target: knowledge workers who gave up on Todoist because it had too many features.

2. Email only note taker

Send a note to save@notes.email; the subject becomes the title. Forward any email to archive it. Search by replying with find: keyword. Weekly digest. Tagged automatically by the LLM. No folders. No app.

3. Email only bookmark manager

Forward any link you receive or visit to read@laterbox.email. The service fetches the page, extracts the text, emails you a reading friendly version on demand. Weekly "reading list" email with unread bookmarks.

4. Email only habit tracker

Daily check in email at 8pm: "did you meditate today?" Reply Y or N. Weekly summary with streak. Monthly trends. Pure plaintext. Good addiction loop because the daily email is easy to miss and easy to reply to.

5. Email only journal

Send a daily reflection to today@journal.email. Monthly email summarizes your entries with LLM analysis. Year end review email is the premium upsell.

6. Email only read later

Forward an article to a per user address; the service sends it back cleaned up at your chosen reading time. Optional: converts long articles to audio attached as MP3.

7. Email only expense tracker

Forward every digital receipt to expense@receipts.email. LLM extracts merchant, amount, category, date. Monthly report email with totals and CSV attachment for taxes. Quarterly category breakdown.

8. Email only password reminder (never storing passwords)

Not a password manager; a hint manager. Send your own memory hint, encrypted, retrievable only by you. Zero security critical data on the server.

Work and team

9. Email only standup

Daily 9am email: "what did you do yesterday, what are you doing today, any blockers?". Each team member replies. 10am digest goes to the whole team. Zero meetings. Team plan at $5/seat.

10. Email only 1 on 1 prep

24 hours before a recurring 1 on 1, email both people: "what do you want to discuss tomorrow?" Replies get aggregated into a shared agenda sent to both.

11. Email only hiring CRM

Forward every candidate email (application, recruiter intro, LinkedIn message export) to hire@candidates.email. The product builds a candidate database, dedupes, tracks status, sends weekly pipeline summary.

12. Email only meeting scheduler (x.ai redux)

CC schedule@app on a thread. The product reads the thread, proposes times from your calendar, negotiates with the other party, books the meeting. This is the idea that killed x.ai; in 2026 it works because Claude is the parser.

13. Email only status page

Team members email incident updates to a dedicated address. The product maintains a public status page URL automatically. Subscribers receive incident emails.

14. Email only incident response

Monitor alerts get forwarded into alerts@incident.email. The product dedupes, groups, and pages the on call via email (or SMS via Twilio bridge). Post mortems happen in the email thread.

15. Email only anonymous team feedback

Each team member has an anonymous address to email into. All messages are stripped of sender identity and forwarded to the team lead as a weekly digest. Pure email based anonymous feedback box.

16. Email only sales CRM for solopreneurs

Forward any customer email to log@crm.email. The product builds a per contact timeline, reminds you to follow up, and surfaces dormant leads with a weekly "ghosts" email.

Content and writing

17. Email only blog (Hey World redux)

Email a post to publish@yourblog.email and it goes live at a public URL. Markdown parsing, image attachments, SEO fields in the subject line. Reply to an existing thread to edit the post. $10/month.

18. Email only newsletter editor

Compose a newsletter by emailing the product. The product sends it to your subscribers. Subscribers reply to get unsubscribed. The entire editing experience is your native email client.

19. Email only writing coach

Forward a draft to review@coach.email. The product replies with LLM line edits, a tone analysis, and three suggested rewrites. $20/month.

20. Email only translator for teams

Forward any message to translate@lang.email and get back the translated text plus cultural notes. Useful for internationally distributed teams.

21. Email only book summary service

Email a book title; get back a 5 minute summary. Monthly subscription for unlimited requests. Low margin but high conversion because the first request is trivially easy.

AI and research

22. Email only research assistant

Email a research question to ask@research.email. The product runs a Claude powered research loop and emails a multi page report 10 minutes later. Pay per report or monthly cap.

23. Email only Claude

A Claude chat interface that lives entirely in your inbox. Each email is a turn. Replies maintain conversation history via thread ID. For users who want AI without opening another tab. $15/month.

24. Email only code reviewer

Attach a diff or paste a Git patch in the body. The product emails back a line by line review, plus three suggested refactors, plus a unit test draft. Targets solo developers without a reviewer.

25. Email only deep search across your own messages

Forward the product any message you want indexed. Later, email a question and the product searches your forwarded archive. A personal Perplexity for your own email history.

26. Email only meeting summarizer

Forward a Zoom or Google Meet transcript (most providers email transcripts now). The product replies with a summary, action items, a follow up email draft, and a calendar suggestion for the next meeting.

27. Email only expert consultation

Pay per question. Email a specialized domain question (tax, legal, medical). The product runs a chain of verifications through multiple LLMs and domain tools, emails back a cited answer. Higher margin than general chat.

Developer tools

28. Email only webhook trigger

Email triggers a webhook. Useful for Zapier like automations where the trigger is "I sent an email". Replace Zapier for the 20 percent of workflows that start with email.

29. Email only database query

Send SQL (or a natural language question) to an authorized address. The product runs the query against the connected database, emails the result as a CSV attachment plus a plaintext summary.

30. Email only uptime monitor

Email the product a URL to monitor. Get a weekly uptime report. Outage alerts come as emails. No dashboard to check.

31. Email only form builder

Submit a form template by email; the product generates a public URL; all submissions arrive in your inbox as threaded emails. Typeform for people who hate Typeform.

32. Email only deploy command

CI/CD trigger by email. Send "deploy staging" to an authorized address; the product runs the pipeline and emails back the result. Not a replacement for GitHub Actions; a companion for ops people who want to ship from an airport.

Finance and SMB

33. Email only invoice maker

Email the details ("bill Acme Corp $5,000 for March consulting"). The product replies with a branded PDF invoice. Customer replies PAY and gets a Stripe link. Invoice state is tracked in the thread.

34. Email only invoice chaser

Forward unpaid invoices to chase@overdue.email. The product sends escalating reminders from your own domain on your behalf. Polite first, firmer at day 30, escalated at day 60.

35. Email only bookkeeping

Forward every financial email (invoices paid, bank alerts, receipts) to books@ledger.email. The product keeps a running ledger and emails a monthly P&L plus a CSV export for your accountant.

36. Email only lead qualifier

Forward inbound sales emails to qualify@leads.email. The product replies with a lead score, suggested subject line, and a drafted response. Good fit for solo founders doing their own sales.

Personal and lifestyle

37. Email only therapy journal

Nightly prompt from a therapist trained LLM. Reply with whatever is on your mind. Weekly reflection summary. Monthly pattern analysis. Not medical advice; a structured journaling partner.

38. Email only gratitude practice

Daily 8am email: "three things you are grateful for today?" Reply. Weekly and monthly recap. Very low lift to build, high daily active rate if the hook lands.

39. Email only meal tracker

Forward delivery confirmation emails, photos of plates, or text descriptions. The product builds a calorie and macro log and emails a weekly health summary. No manual logging.

Weird and niche

40. Email only time capsule

Write a message to future you. Specify a date in the subject line. The product emails it to you on that date. Five years. Ten years. Twenty. Pay once per message, or subscribe for unlimited future drops.

Also worth prototyping: email only D&D game master, email only AITA jury, email only wedding RSVP collector, email only family chore board, email only dream journal, email only interactive fiction, email only smart home control bridge, email only local news summarizer, email only language flashcards, email only stock price alerts, email only crypto portfolio tracker, email only fantasy football scoring, email only anonymous confession box. Each of them is a weekend build on top of the same stack.

Part 7: The technical stack

Inbound

Postmark Inbound. Cleanest API, best documentation, $15/month minimum. Parses HTML, plaintext, attachments, headers. Use this if you care about quality.
Mailgun Routes. More flexible routing rules. Similar price. Slightly older API.
SendGrid Inbound Parse. Works fine. Twilio owned, which some founders prefer.
AWS SES plus Lambda. Cheapest at scale, most work to set up. $0.10 per 1,000 inbound emails. Use once volume justifies the ops overhead.
CloudMailin. Small and focused, good for prototypes.
ImprovMX or Forward Email. Not inbound parsers; they forward to a destination. Combine with a lightweight parser for cheap.

Outbound

Postmark for transactional. Best deliverability by reputation. $15/month for 10,000 emails.
Resend for modern API and React Email templates. $20/month for 50,000 emails, very developer friendly.
AWS SES for cheap at scale. $0.10 per 1,000. Deliverability requires warming and a solid reputation.
Loops.so for marketing flavored transactional. Not ideal for high volume transactional but good for onboarding sequences that feel personal.

Parsing

Claude Sonnet 4.6 is the current default for structured extraction. Fast, cheap, reliable at JSON output. Cost per parse is around $0.0005 to $0.002.
GPT 5 for comparison. Similar quality. Different rate limits.
Gemini Flash if cost is the constraint.
A local small model (Llama 4, Qwen 3) for self hosted operators who want zero vendor lock in.

DNS, deliverability, reputation

SPF, DKIM, DMARC configured on the sending domain. No shortcuts. Postmark and Resend walk you through this.
Dedicated sending subdomain. mail.yourapp.com, not the bare root.
Reply to address should be the same subdomain as the from address.
Warm up the domain for 2 to 4 weeks before launch. Mailreach, Instantly, or Lemwarm for warming.
Monitor bounce rate (under 2 percent) and complaint rate (under 0.1 percent).

Storage

Postgres or SQLite (the new Turso or Litestream style) is plenty. The schema is usually: users, aliases, threads, messages, actions. Attachments go to S3 or R2 with a signed URL.

Billing

Stripe. One web page: the Stripe Customer Portal. Every other interaction stays in the inbox.

Total cost at 1,000 users

Postmark Inbound + Outbound: $30/month
Claude API at 10 parses per user per day: $300/month
Database and hosting (Fly.io, Railway, Render): $50/month
Domain + monitoring + misc: $20/month
Total: roughly $400/month to run a product serving 1,000 users. At $10 per user per month, gross margin sits north of 95 percent.

Part 8: Distribution and go to market

Product Hunt

Email only products launch exceptionally well on Product Hunt because the "try it now" call to action is an address, not a signup form. Users try the product inside their own inbox during the launch day; activation is instant. Historical data: FollowUpThen, Nudgemail, and Amy all had strong Product Hunt launches.

Productivity subreddits

r/productivity, r/Notion, r/todoist, r/selfimprovement. The demographic is hungry for tools that save them from switching context. "No app to install, just send an email" is the hook. Do not shill; share when people ask for recommendations.

Indie Hackers, Hacker News, Lobsters

The developer demographic appreciates clever architecture. A Show HN post titled "I built a task manager with 0 screens: it's just email" gets the comment section unprompted. Technical depth in the post body converts the skeptics.

Twitter and LinkedIn

The demo video is a screen recording of an email being sent and a reply landing in the inbox. Short, visual, self explanatory. Repost with different use cases weekly.

Cold email (meta)

For B2B email only products, cold email is the natural distribution channel. You are literally selling email as a product, in an email, to someone who reads email. Activation friction is zero because they can reply to your cold email to try the product.

Referral loop via CC

When a user CCs a product address on a thread, the other participants see the product in action. Many of the best email only products get new signups from these organic introductions. Make sure the from address is brandable and the footer includes a subtle "built by yourservice.com" line.

Templates gallery

A single web page listing 50 use cases ("how to add a task by email", "how to schedule a meeting by email") that ranks on long tail queries. This is the only web page the product needs, and it does double duty as SEO and as a user manual.

Part 9: Risks and failure modes

Deliverability

If your replies land in spam, the product is broken. SPF, DKIM, DMARC are mandatory. A dedicated subdomain is mandatory. Domain warming is mandatory. Monitoring bounce and complaint rates is mandatory. Expect to spend 10 percent of your engineering time on deliverability forever.

Provider dependency

Postmark, Mailgun, SES, and Resend are all single points of failure. Build abstraction over the provider from day one so you can swap. Keep a second provider warm for failover.

Abuse vectors

Someone can spoof an email and impersonate a user. Validate DKIM on every inbound message. Reject unsigned messages. Rate limit per sender. Ban known spam IPs. These are solved problems but they require vigilance.

HTML parsing edge cases

Real world emails are messy. Forwarded messages have headers embedded in the body. Signatures are noisy. HTML gets mangled by corporate gateways. Your parser has to handle all of it. Budget for a long tail of edge case fixes.

Async UX friction

Users expect instant feedback. Email is instant in 2026 (sub second delivery) but the perceived expectation is "app like". If your reply takes 60 seconds, the user wonders if it worked. Solution: send an immediate acknowledgment email ("got it, working on it") and a follow up reply when the action completes.

Settings UX

"How do I change my preferences?" is the hardest question for an email only product. Options: dedicated settings email address with a command grammar, natural language "change my reminder time to 7am", or a small Stripe style portal for settings only. Pick one and document it aggressively.

Support

When something goes wrong, users have nowhere to click. Make sure every reply includes a "reply HELP for support" line. Staff a human fallback for the first year. Budget for it.

Dashboard temptation

Investors will ask for a dashboard. Power users will ask for a dashboard. The PM in you will want a dashboard. Resist. The moment you ship a dashboard, you dilute the core thesis and pay the cost of building and maintaining a second surface area. Ship the dashboard only if the data strongly suggests you need it, and only as a read only view.

Part 10: A 30 day build plan

Days 1 to 5: infrastructure

Register the domain. Set up SPF, DKIM, DMARC.
Sign up for Postmark (inbound + outbound). Configure the inbound webhook endpoint.
Deploy a minimal backend (Node, Go, Python, whatever is fastest) on Fly.io or Railway.
Test inbound and outbound with a throwaway address. Send an email, receive the webhook, reply from the backend.

Days 6 to 10: core loop

Pick one idea from Part 6.
Implement the parse: one Claude prompt, JSON output, strict schema.
Implement the action: create, read, update based on the parse.
Implement the reply: plaintext first, threaded via In Reply To, personal tone.
Test with 10 real messages from your own inbox.

Days 11 to 15: state and edge cases

Thread state: connect replies to the original thread via Message ID.
Parse forwarded messages, signatures, HTML, attachments.
Rate limiting, DKIM validation, sender verification.
Error reply flow: "I did not understand, can you rephrase?" with examples.

Days 16 to 20: onboarding and billing

First email is the sign up. Create a user record on first inbound message from a new address.
Welcome reply explains the commands.
Stripe Customer Portal for billing. One URL, linked from every reply footer.
Free trial with a usage cap.

Days 21 to 25: landing page and demo

One web page. The hero is the email address. The rest is use cases.
A 30 second demo video showing an email going out and a reply coming back.
FAQ section covering settings, privacy, security, cancellation.
Templates gallery with 20 real world examples.

Days 26 to 30: launch

Submit to Product Hunt. Prepare a crisp tagline.
Write a Show HN post explaining the architecture. Technical depth wins.
Post in two or three relevant subreddits, carefully.
Tweet a demo video. Cross post to LinkedIn with a B2B angle.
Set up weekly email for users summarizing their activity. This is both retention and second order distribution.

Part 11 bonus: Cute French domain candidates (available April 2026)

One hidden cost of shipping an email only product is picking an address that is easy to type, easy to remember, and does not feel corporate. The domain is the whole brand when the product lives in the inbox. "yourproduct.email" only works if "yourproduct" is a great word.

French flower and garden vocabulary is a gold mine for this. The words are short, visually soft, and mostly still unclaimed across the newer TLDs. The list below was checked via RDAP on April 11, 2026; every entry was free to register at the time of the check. Verify with your registrar before buying; stocks move fast once a list like this circulates.

For email only blogs (Hey World redux territory)

coquelicot.blog. "Coquelicot" is the red field poppy; one of the most evocative French words you can slot into a .blog domain. Near perfect for a service where publishing means sending an email.
pensee.blog. "Pensée" means both "thought" and "pansy flower". Double meaning. Ideal for a reflection blog emailed in daily.
muguet.blog. Lily of the valley, tied to May Day in France and the tradition of offering a sprig to someone you love. Tender brand.
rosee.blog. "Rosée" means morning dew. Clean fit for a daily blog.
marguerite.blog. Daisy. Classic, approachable, does not take itself too seriously.
lavande.blog. Lavender. Evokes Provence and slowness.
pousse.blog. "Pousse" is a sprout; "pousser" is to grow. Perfect for a blog that compounds over time.
graine.blog. "Graine" means seed. Each post plants something.
eclore.blog. "Éclore" means to bloom or to hatch. For a blog that opens up post by post.
fleurir.blog. "Fleurir" means to flourish. Motivational without being cringe.
jardin.blog. "Jardin" means garden. A blog as a garden you tend.
violette.blog. Violet. Intimate, confessional tone.
buisson.blog. "Buisson" means bush. Modest, quiet, for someone writing from the margins.
tulipe.blog. Clean, single syllable feel, works in English too.
dahlia.blog. Autumnal, rich, uncommon.
jasmin.blog. Scent, intimacy. Also a strong fit for a perfume or sleep adjacent project.

For email only dating and romantic correspondence

coquelicot.love. Red poppy plus the .love TLD. The archetype.
muguet.love. May 1 in France is the day you give a sprig of muguet to someone you love. The domain carries the whole story.
pensee.love. "Thinking of you" baked into the domain.
petale.love. Petal. Soft, intimate.
lys.love. Short, elegant; the lily is a symbol of purity in French heraldry.
pivoine.love. Peony. In East Asian traditions, peonies symbolize romance and honor.
fleurir.love. To bloom, to fall in love; the verb fits both.
eclore.love. To open up. Literally what happens in early love.
rosee.love. Morning dew on the first meeting.
hortensia.love. Hydrangea. Long, distinctive, memorable.
camelia.love. Camellia. Tied to the French novel La Dame aux Camélias.

For email only notes, journals, memory

pensee.email. The clearest match in the whole list. Every email is a pensée.
rosee.email. Morning dew; a daily notebook delivered at 7am.
brume.email. "Brume" means mist. For half formed notes and fuzzy thoughts.
serre.email. "Serre" means greenhouse. A contained, warm place where ideas incubate.
graine.email. Seed. For a notes app where every note can be watered later.
muguet.email. Tender, personal. Good fit for a gratitude journal.
lavande.email. Calming brand for an evening reflection product.
mousse.email. "Mousse" means moss. For a quiet, slow, foresty notes app.

For email only tasks, reminders, FYIs

coquelicot.fyi. The .fyi TLD plus a soft word fights the sterile feel of most productivity tools.
muguet.fyi. Cute, short, distinctive.
marguerite.fyi. Longer but memorable.
tulipe.fyi. Clean on the eye.
fleur.fyi. Short, cheap, to the point.
pivoine.fyi. Distinctive, slightly more formal.
jardin.fyi. A garden of open loops.

For email only newsletters and digests

bouquet.garden. A bouquet picked from a garden; a newsletter as a curated bundle from a larger field.
nectar.email. Nectar is what bees come back for. The thing worth subscribing to.
pollen.ink. Pollen spreads; ink writes. A newsletter metaphor baked into the name.
bouquet.love. For a love letters newsletter.

For email only habit tracking and growth

pousse.email. Sprout, literally. Every day you grow a little.
pousse.blog. Growth log in public.
graine.garden. Seed in a garden. The daily input becomes the yearly harvest.
eclore.email. Bloom. For a habit tracker that celebrates small wins.
fleurir.email. Flourish. Motivational without being hustle flavored.
verger.garden. "Verger" means orchard. Longer cycles, slower rhythm, fruit trees instead of sprouts.

For email only communities and shared spaces

jardin.club. A garden club. Perfect for a book club or a shared reading circle operated by email.
iris.love. Iris was the Greek messenger goddess; a fitting metaphor for a circle where messages travel between people.

For email only AI assistants

iris.blog. Iris as divine messenger is the right metaphor for an email based LLM loop.
pensee.ink. Thought plus ink. A partner for writing.
pensee.email. Double meaning, medium baked in.
coquelicot.ink. Strong visual; a red poppy writing its own line.

The .page discovery: almost everything is open

Special mention for the .page TLD. At ~$10/year it is the cheapest of the bunch, it is Google owned (HTTPS is enforced by default for every .page domain, which is a small but real security win), and almost the entire French flower vocabulary was available when this list was checked. 30 of 32 candidates came back free.

Available .page domains (April 11, 2026 check):

coquelicot.page, muguet.page, pivoine.page, marguerite.page, jasmin.page, tulipe.page, lys.page, iris.page
dahlia.page, lavande.page, mimosa.page, hortensia.page, camelia.page, pensee.page, petale.page, rosee.page
bouquet.page, jardin.page, prairie.page, verger.page, serre.page, mousse.page, buisson.page, ruche.page
brume.page, eclore.page, fleurir.page, graine.page, racine.page, pollen.page, nectar.page, rose.page, fleur.page

Two were taken: violette.page and pousse.page. Everything else in the list was open.

The .page TLD is slightly web centric in feel (it reads as "a page"), so it is a better match for products where the email loop has a public output (a blog post, a profile, a published note) than for pure internal tools. But at $10, it is the cheapest way to lock down the brand while you decide which operational TLD to use alongside it.

Notes on price and TLD personality

.blog around $30/year. Credible but not cheap.
.email around $12 to $15/year. The most on brand TLD for this category.
.love around $25 to $30/year. Narrow but exactly right for dating, gratitude, and relationships.
.fyi around $20/year. Informal, friendly, great for reminders and notes.
.garden around $25/year. Uncommon enough to feel personal; perfect for any growth themed product.
.ink around $30/year. Writing adjacent vibe.
.club around $12/year. Cheap, community flavored.
.page around $10/year. Google owned; cheap; clean.
.cafe around $30/year. Cozy.
.paris around $25/year. Strong local flavor if you want to lean French.

Sequencing tip: grab the .email or .page variant first (cheap, functional, core brand) and park a .blog or .love sister domain for later if the product finds its audience. Total year one domain cost for a typical project sits between $12 and $50.

One caveat on French accents. Words like éclore, rosée, pensée technically exist as IDN variants, but most registrars make them painful to buy, and users cannot type accents on a mobile keyboard without extra taps. Every domain above uses the ASCII form (eclore, rosee, pensee), which is the safer default. If you later want the accented version, buy the ASCII one first and add the IDN as an alias.

13. Closing notes

Email only as a category got buried under the failures of x.ai and Clara Labs. Everyone assumed the lesson was "email as an interface does not work". The actual lesson was "natural language parsing was too hard for the tools we had". That constraint is gone. The idea it buried deserves a second look.

Three pieces of advice for anyone taking this seriously:

Pick a narrow parse. The products that fail are the ones that try to handle any email in any format. The products that win handle exactly one kind of intent and say "I do not understand" to everything else. Narrowness is a feature.
Ship the plaintext first. Pretty HTML templates come later. The first version of every reply should be short plaintext that works in any client, including the terminal mail reader on a 20 year old server.
Budget for deliverability forever. If you do not take this seriously, the whole product fails silently in spam folders and you never notice. Monitor bounce and complaint rates from day one. Wake up if they drift.

The rest is execution. Pick an idea. Wire up Postmark. Write one prompt. Ship the reply. Most people will never attempt this because dashboards feel safer. That is why the opportunity is still open.