Buttondown

Duke wanted a newsletter tool that did not feel like a growth-hacked social network. Buttondown shipped as plain Django with marketing pages in the same codebase — a decision he later mildly regretted but never rewrote into microservices.

On the Running in Production podcast he described choosing boring tech so he could iterate after hours without learning a new framework per quarter.

Growth meant scheduling and deliverability, not re-architecture. Duke built django-rq-cron after Heroku’s scheduler missed windows — sensitive crons now run inside the same RQ workers that send mail.

He split logic into ~8 Django apps (`emails` sun, `api`, `monetization`, etc.) but kept one deployable unit on Heroku with roughly a dozen dynos — enough headroom without hiring a platform team.

Duke’s 2022 “how I organize Django apps” post is the receipts: 45k lines, checker framework for invariants, Stripe Connect mirrored in Postgres for speed — still not Kubernetes.

Buttondown’s public /stack page lists every dependency and what they removed (Heroku Redis → other providers → Postgres-backed caching experiments). That transparency is the anti-over-engineering flex.