Updates 12 April 2026 Updated 21 April 2026 2 min read By Bill Keeling-Ogilvie

Progress update: email and what's next

Not only is billblogs.uk my personal blog site, but it’s built on my own hosting infrastructure I’m developing at billko.uk.

This is a result of me figuring it would be pretty cool to have a blog, but then being a full stack web developer plus ADHD plus asking Claude lots of questions… and I overengineered myself into setting up a multi-tenant site hosting platform. Anyway, below is what I’ve been working on very recently.

Emails: all three flavours

Email turned out to be a bigger part of this than I expected. I learned it comes in three distinct forms for a hosting stack like this.

Client business email is the easiest to think about: it’s not my problem to host. Email is a headache to run yourself. Deliverability, IP reputation, SPF/DKIM/DMARC, spam blacklists. It’s much better as the host to handle the DNS side and let the client manage their actual mailboxes through Google Workspace or Zoho. Clean split, sensible liability boundary.

WordPress transactional email is a different beast. This covers things like password reset links, form submissions, and order confirmations. By default, WordPress tries to send these via PHP’s mail() function, which either fails silently or gets spam-filtered immediately from a server IP. The fix is routing through a proper transactional email service. I’ve opted to use Resend, which has a very generous free tier and handles deliverability properly. This one is squarely my responsibility to bake into my sites.

Local dev email is the third piece. You need a way to test that emails are actually being sent without firing real messages at real inboxes. The standard tool for this is Mailhog: a lightweight SMTP server that catches all outgoing mail and displays it in a web UI instead of delivering it. I’ve added it to my local dev environment so I can inspect emails without any of them going anywhere real.

Getting all three sorted means the email story is covered end to end: local testing, production sending, and client mailboxes.

What’s next: a custom headless WordPress plugin

The next chunk of work is more interesting. I’m building a custom WordPress plugin to improve the headless experience across my sites.

Running WordPress headless (where my frontend consumes the WordPress API and WordPress is purely a CMS) is well-trodden territory, but the default setup still has rough edges. The plugin will clean up and extend the API responses to expose exactly the data my frontend needs, and lock down the WordPress CMS so it only serves the API and admin interface and nothing else.

The goal is for this to ship as part of my base product so every site gets the improved headless setup for free. Writing it myself rather than reaching for a third-party plugin also means I understand exactly what it’s doing and can extend it as requirements grow.