Why we built WriteKit

I’ve been blogging for over a decade. Built sites with Hugo, rolled my own from scratch, tried Ghost, WordPress, Medium, Hashnode, and Dev.to. They all fall short in the same frustrating ways.

The problem with existing platforms

Platform	Monthly Active Users	The Catch
Medium	100M+ readers	They paywall your content, own your audience
Dev.to	8.8M developers	Your content lives on their subdomain
Hashnode	1M+ users	Better, but still platform-dependent
Ghost	3M+ sites	Node.js + MySQL = heavy infrastructure

Medium treats your content like their content. In 2017, they pivoted to a metered paywall system—suddenly readers hit a wall on your articles. They’ve changed monetization rules three times since then.

Hashnode and Dev.to are better—they’re built for developers. But they’re still platforms that own your distribution. Your SEO juice flows to their domain, not yours.

Ghost is legitimately good software. But it requires:¹

• Node.js 18+ runtime
• MySQL 8.0 database
• 1GB RAM minimum (2GB recommended)
• A server to maintain

For a personal blog? That’s infrastructure overhead most developers don’t want to manage.

Static site generators (Hugo, Eleventy, Jekyll) solve the ownership problem, but the moment you want dynamic features, you’re assembling a Frankenstein:

• Disqus for comments (loads 2MB+ of JavaScript)
• Mailchimp for newsletters ($20/mo at 500 subscribers)
• Google Analytics (privacy nightmare)
• Cloudinary for images
• Algolia for search

Each service requires separate accounts, APIs, billing, and maintenance.

What developers actually need

After years of frustration, I compiled what I actually wanted:

• Write in markdown—not a WYSIWYG that mangles code blocks
• Own my data—my posts, my database, export anytime
• Analytics that don’t suck—know what resonates without tracking pixels
• Comments that work—without embedding third-party scripts
• Newsletter built-in—no integration hell
• Fast by default—not “fast if you configure it right”
• API access—because I’m a developer

The SQLite insight

The architecture clicked when I started thinking differently about multi-tenancy.

Traditional SaaS puts everyone in one database with a tenant_id column. Your data sits next to everyone else’s. A bug could leak data. Exports require complex queries. You’re trusting the platform completely.

What if every blog was its own SQLite database? Not a row—an actual file that belongs to you.

/data/tenants/
├── your-blog.db      # Your entire blog: posts, comments, analytics
├── another-blog.db
└── third-blog.db

You could literally download your entire blog and run it locally. That’s true ownership—not “we’ll email you a JSON export eventually.”

The technical bet

We built WriteKit on boring, proven technology:

Go

Compiles to a single binary. No runtime dependencies. Handles thousands of concurrent connections with minimal memory. Used by Cloudflare, Docker, and Kubernetes.

SQLite

35+ years of development. Trillion-dollar companies trust it. The most deployed database in the world—literally on every smartphone.²

React

Only where it matters. The blog reader is server-rendered HTML. The admin dashboard is a SPA because editors need real-time feedback.

This stack means:

• Cold start: 0ms (no serverless spin-up)
• Memory per tenant: ~2MB idle
• Page response: <50ms average

Built for developers who ship

WriteKit isn’t trying to be everything to everyone. It’s built for developers who:

• Write technical content and care about code formatting
• Want to understand their audience without surveillance capitalism
• Value owning their data over platform convenience
• Ship consistently and need tools that stay out of the way

We’re not building the next Medium. We’re building the blogging tool we wished existed.

---

If you’ve felt the same frustrations, try the demo. Fifteen minutes is all it takes to see if this is what you’ve been looking for.

Own your words. Own your blog.