Substack added a scheduler. Here's why I kept building PubQ anyway.
Substack finally added native scheduling for Notes. Good, it validated the problem.
But their scheduler does one thing: pick a time, post a Note. That's it. No analytics. No calendar view. No way to see your whole week at a glance. No drip queues. No bulk scheduling.
I had already built PubQ to solve the scheduling gap. When Substack shipped theirs, I kept going, because the real problem was never just "post later." It was "manage your entire Notes strategy in one place."
What PubQ does that native scheduling doesn't:
- Calendar view -+-> see your full week of scheduled Notes visually
- Analytics -+-> which Notes are actually driving impressions, likes, and subscriber growth
- Drip queues -+-> automated sequences that release Notes over time on a cadence
- AI generation -+-> writes Notes in your voice by analyzing your published content
- Bulk scheduling -+-> queue a week's worth of Notes in one sitting
How it works under the hood (for the technical folks):
Substack has no public API. PubQ captures your session cookie via a Chrome extension, encrypts it AES-256-GCM, and posts at schedule time using TLS fingerprint spoofing (curl_cffi with Firefox impersonation). Looks browser-native to Substack.
Stack: Django, HTMX, Tailwind, curl_cffi, Supabase (Postgres), QStash for cron. No React. Pure Python.
Pricing:
Free: 5 notes/month, no card.
Basic: $5/mo -+-> 30 notes, calendar view.
Pro: $12/mo (launch price) -+-> unlimited notes, analytics, drip queues, AI generation.
Lifetime: $149 one-time -+-> 500 founder spots.
Happy to answer anything about the build, the TLS fingerprinting, or how we're positioning against a platform feature.
