A redesign for an educator with 571 posts and counting: a fast new front end on the WordPress that already held his content, and automations that publish for him.
Joel Bomgar has been teaching people about Bitcoin for years: hundreds of Facebook Live videos, a podcast, and a WordPress site that holds all of it. The site had grown one plugin at a time. A page-builder theme drew every page, and each post made about a hundred requests and loaded two megabytes before anyone pressed play.
Behind it ran the automations that kept everything publishing: new videos into posts, and posts onto Joel's Facebook page. They worked until they didn't. Three of them reported success on every run while posting nothing, and nobody could tell.
03The SolutionWhat shipped
I kept WordPress, where all of Joel's content already lived, and moved it behind the scenes. It still holds every post, but visitors now get a new front end built with Astro and hosted on Cloudflare: a fast static site that rebuilds itself whenever something is published.
The redesign organizes 571 posts around the way people actually learn: learning paths for beginners and intermediates, a resource library whose search reaches into the video transcripts, a podcast page, and a free ebook with its own sign-up. Every post with a video opens on a lightweight preview instead of a full YouTube player, so a post page now loads about 0.6 MB instead of 2 MB.
Nothing got lost in the move. Every old post address redirects to its new home, checked on every build against Cloudflare's rule limits, and the email sign-up goes straight to SureContact with the campaign it came from attached.
Most of what appears on joelbomgar.com is published without anyone touching the site. When Joel adds a video to a particular YouTube playlist, an OttoKit automation turns it into a WordPress post, with the title, description and video, and tells the team in Slack. Its last step asks GitHub to rebuild the site, and about six minutes later the new page is live. If that step ever fails, a scheduled rebuild every six hours picks the post up anyway.
Joel's Facebook page runs the same way. Six automations work through queues of posts kept in a shared Google Sheet: messages, graphics, text posts and reposts, each on its own schedule. Each one picks the next row, posts it as a photo or as text depending on what the row holds, marks it as posted, and starts the queue over when it runs out.
The part I'm proudest of is the part nobody sees. When those three Facebook automations reported success while posting nothing, I traced it through their run logs to a branch wired to the wrong path, and rebuilt them. When Joel's own firewall began turning away the build servers, quietly producing a site with no posts, I gave every build a key the firewall lets through. An automation that fails silently is worse than none, so every one of these reports what it did.
6 views · tap to enlarge
01What happens after Joel publishes02The seven automations in OttoKit03New video to WordPress post, in OttoKit04The Facebook queue with its photo or text branch05OttoKit run history, every run completed06Mobile pipeline
05Gallery13 views · tap to enlarge
01Home page, “What is Bitcoin?” section02Home page learning paths03Navigation menu open04Beginner learning path05Resource library06A post with its video and audio07Podcast page08Free ebook sign-up09Mobile home10Mobile menu11Mobile post12Mobile podcast13Mobile resources
06Before and afterDrag the handle
Beginner — Desktop01 of 04
Before
After
Beginner — Mobile02 of 04
Before
After
Podcast — Desktop03 of 04
Before
After
Podcast — Mobile04 of 04
Before
After
Drag the handle, or focus it and use ← → (Shift for larger steps), Home and End.
