Why I forked Mailcheap for the Collective

Every business in the Collective needs a way to stay in touch with the people who care about it. A launch gets attention once. An email list gives us a way to keep showing up with something useful.

That’s where Mailcheap fits. It’s a newsletter application we can run ourselves: keep contacts, write campaigns, send emails and publish past issues on the web.

I forked Marc Lou’s open-source Mailcheap and adapted it for Cloudflare. A fork is a copy of an existing project’s source code that we can develop in our own direction. The original project supplies the foundation, and its MIT licence and attribution stay with the code.

Why make a fork?

For the Collective, the reason is practical. I want reusable systems that make each new business easier to operate. Email is one of those systems: welcome a new subscriber, explain what we’re building, share useful work and give people a reason to come back.

The original application already had the dashboard, editor and newsletter workflows. The fork keeps those capabilities and changes how the application runs underneath.

It now runs on Cloudflare. Contacts and campaign records sit in its database, uploaded images in its file storage, and background sending jobs in its queues. That removes the need to operate separate MongoDB, Redis, scheduling and image-storage services for this application.

Amazon SES still delivers newsletters and subscriber messages. Cloudflare runs the application around that delivery. For me, that is a useful division: reuse the email delivery service and bring more of the application into the infrastructure I already work with.

What is available

The public repository includes:

• A dashboard for newsletters, contacts and campaigns.
• An editor, image uploads and test sends.
• Welcome emails, opt-in confirmations and re-engagement messages.
• Scheduled campaigns, tracking links, reports and public issue archives.
• An API for adding contacts and creating campaign drafts from other applications.
• An optional transactional email API for messages such as password resets and receipts, using Cloudflare Email Service.

That last distinction matters. A newsletter is an ongoing relationship someone subscribes to. A receipt or password reset is a service message triggered by an action. The fork supports both, with separate delivery configuration.

An agent can help prepare a campaign through the API. Sending a campaign remains an action in the dashboard, so preparing a draft doesn’t unexpectedly email the whole list.

What running it involves

This is software you can deploy in your own account. It includes setup scripts, a deployment guide and optional GitHub deployment workflows. Sending starts disabled until the email provider and sending domain are configured.

Self-hosting still involves work: domain verification, delivery monitoring, managing subscribers and paying for infrastructure and email usage. The point is to have a system we understand and can adapt as the portfolio grows.

The repository has also prepared a way to adapt changes from the original project with an agent and submit them for human review. That automation needs its own setup and is currently inactive; it doesn’t silently update or deploy anyone’s installation.

The audience is the reason

The useful outcome is a direct relationship with people who have chosen to hear from us. We can tell them what shipped, ask what they need and learn which problems are worth solving next.

As the Collective’s audience grows, each new idea gets a bigger spotlight. Mailcheap is part of making that relationship something we can maintain across the portfolio. A product may change, but we can keep earning the attention of the people who found it useful.

The fork and setup instructions are public. If you run newsletters or understand a market that needs a better email workflow, that’s the kind of experience I’d like to build around.