What Cloudflare’s Move to EmDash Teaches Us About Building Tools You Actually Use
I finished reading Cloudflare’s post about moving their blog to EmDash and realized the real story isn’t the tech stack—it’s the habit of using your own creation as the harshest test. The team frames this as “Customer Zero,” a cultural value that pushes them to run Cloudflare’s own products on their infrastructure before anyone else sees them. That mindset caught my attention because it mirrors a question I ask myself every time I tweak DigestPress: would I rely on this change if it were the only way I got my daily digest?
Why Customer Zero Matters
The article quotes Cloudflare’s internal Codex:
We don’t just build products for others; we build them to run Cloudflare itself. We are our own first, most demanding customer.
Reading that, I thought about the scheduled‑digest model that DigestPress uses instead of an endless feed. When I decided to deliver issues only at a set time, I did it because I hated the anxiety of checking for new content every few minutes. I wanted to know that, if I missed a delivery, the world wouldn’t end—and that the system would be reliable enough that I could trust it with my own reading time. That decision wasn’t driven by market research; it was driven by my own frustration with the status quo.
Cloudflare’s emphasis on dogfooding also explains why they caught the scheduled‑post bug in EmDash version 0.18.x before it affected readers. They treated their blog as a stress test, not a showcase. That kind of rigor is rare in side‑projects, where it’s tempting to ship a feature that works for a demo but falls apart under real‑world load. By insisting on being the first user, Cloudflare forces its teams to confront edge cases early, which ultimately improves the experience for everyone else.
What This Means for DigestPress
I’ve adopted a similar, though more modest, habit: before I roll out a new filtering rule or change the EPUB styling, I run the issue through my own Boox and note where the flow feels clunky. If I find myself wanting to skip a section or adjust the font size mid‑read, I know the change needs more work. This practice has kept me from adding features that look good on paper but irritate me in actual use—like a “related articles” sidebar that would have cluttered the clean, distraction‑free layout I value.
The Cloudflare post also reminded me that dogfooding isn’t just about catching bugs; it’s about aligning the product’s values with the creator’s own needs. When I built DigestPress, I chose e‑ink delivery because I personally find back‑lit screens tiring for long sessions. That choice shapes every design decision, from the lack of infinite scroll to the emphasis on typographic clarity. If I ever start optimizing for metrics that don’t reflect my own reading pleasure, I’ll lose the compass that keeps the tool honest.
Where I Push Back
While I admire the Customer Zero ethos, I think it can become a blind spot if taken too literally. Cloudflare’s infrastructure is massive, and their ability to absorb a faulty release is far greater than that of an indie maker like me. If I were to treat every DigestPress change as a life‑or‑death test for my own workflow, I’d likely ship slower and miss opportunities to experiment with ideas that might benefit other readers even if they don’t suit my taste.
A healthier balance, in my view, is to use personal use as a primary filter but to supplement it with structured feedback from a small group of trusted readers. That way I keep the product grounded in my own experience without becoming insulated from the diverse ways people actually consume digests.
Next Action
If you build any kind of tool—whether a reading app, a newsletter script, or a personal wiki—spend one full day using only the latest version of your own work for its intended purpose. Notice where friction appears, and let those observations guide your next round of changes. You’ll often find that the most valuable improvements come not from chasing trends, but from solving the annoyances you yourself encounter every day.
the original piece
How DigestPress curates your issue
Why we built DigestPress for e-ink
DigestPress.