How one mailbox for everything breaks

The setup grows innocently. Your first project gets a contact@ alias that forwards to your personal Gmail. The second gets the same treatment. Then a landing page needs a form, so a form endpoint starts emailing you too. By project ten you have ten forwarding rules, a filter per domain, a label tree you stopped grooming months ago. And one mailbox pretending to be ten.

Then the specific failures start:

  • Messages get missed.A bug report from a paying user of one project lands between another project's launch spike and your regular personal mail. Your mail client has no idea these are different products. You find it four days later.
  • Context gets lost."Hey, the export is broken." Which export? Half the messages never name the project, and the only clue is a To: header buried behind a forward.
  • You can't mute one project. Launch week for one product floods the mailbox for all of them. The only mute switch you own covers your entire life.
  • You can't hand anything off. A collaborator joins one project, and its messages live in your personal account. Forward each one manually or share your login. Both are bad.
  • Dead projects never die.The forwarding rule outlives the product. Two years on you're still getting spam for a domain you let expire, and you can't delete the filter with confidence because it's tangled with nine others.

None of these are filter problems. They're a topology problem: you're pushing N products through one channel, and labels are duct tape.

What one inbox per project changes

Flip the model. Each project gets its own inbox: its own email address, its own form endpoint, its own notification rules. Messages never mix, and everything that was global becomes scoped:

  • Muting is scoped. Silence the launch-week project; the other nine keep pinging you.
  • Handoff is scoped.A collaborator gets that one project's messages (in a shared Discord or Slack channel, or a team inbox) without ever touching your mailbox.
  • Archiving is scoped.Project's dead? Archive its inbox. The channel closes, the history stays readable, nothing else is disturbed.
  • Context is free.If a message is in the inbox, it's about that project. No detective work on headers.

You can build this yourself with a paid mailbox per project or a catch-all domain and a pile of routing rules (people do). But it costs either money per address or an afternoon per project, which is exactly why nobody keeps it up past project three. The fix is making a new inbox cost nothing.

The setup, in practice

This is the exact thing we built mailcontact for. Create a project and it comes with two sources feeding one inbox:

An email address that works immediately. yourproject@mailcontact.app is live the second the project exists: no DNS records, no mail server, nothing to verify. Put it in your footer and you're done. (How the address works.)

A form endpoint for the contact form on your landing page. Plain HTML posting email and message (plus optional name and subject), submitted with a few lines of fetch so visitors stay on the page:

<form id="contact">
  <input name="email" type="email" placeholder="you@example.com" required />
  <textarea name="message" placeholder="What can we help with?" required></textarea>
  <button type="submit">Send</button>
</form>

<script>
  const form = document.getElementById("contact");
  form.addEventListener("submit", async (event) => {
    event.preventDefault();
    await fetch("https://mailcontact.app/api/forms/your-form-id", {
      method: "POST",
      body: new FormData(form),
    });
    form.innerHTML = "<p>Thanks, message received.</p>";
  });
</script>

Both land in the same project inbox, and a notification (Discord, Slack, email, or a webhook) fires the moment something arrives, so you never poll yet another inbox. Ten projects, ten inboxes, zero new tabs. The docs cover the details, and the free plan covers your first two projects (pricing).

The snippet above is stack-agnostic on purpose, because the ten projects are rarely built with one thing. There are setup guides per stack if you want the version that matches what you're actually shipping: Next.js, Astro, SvelteKit, Hugo, or the full list.

To be clear about scope: mailcontact is deliberately not a helpdesk. No tickets, no SLAs, no assignment queues: just a clean inbox per project for the real messages real projects get. It's in beta; join the waitlist to get access.

Separate channels are just ops hygiene

Nobody runs ten services into one log file and greps for the service name. Nobody sends ten apps' errors to one monitoring project. Everywhere else in your stack, one channel per product is basic operational hygiene. Contact email is the odd one out only because isolation used to be expensive: a domain here, DNS records there, a paid seat per address.

When a new inbox costs five seconds instead of an afternoon, the calculus flips. Spinning up a contact channel becomes part of the project boilerplate, like initializing the repo. That's how it should have worked all along.

Your next project deserves its own inbox. So do the nine before it.