There’s a version of building in public where you make consistent progress, ship things on time, and every weekly update is a tidy narrative of wins with light-touch humility thrown in for relatability.
That’s not what this is.
This week I picked a real launch date. Not “Q3 2026” — an actual calendar slot. Product of the Week on a newsletter I respect, week of July 7. That’s six weeks away. The slot is booked. It can’t be changed without embarrassment.
And the moment I locked it in, everything that was vague and flexible became suddenly, uncomfortably concrete.
—
What Actually Shipped This Week
Before I get to the existential bit, here’s what got built.
The biggest item was auto-updates. Dictare uses [Sparkle 2](https://sparkle-project.org/) for macOS updates — the standard framework for Mac apps that don’t live in the App Store. Sparkle checks an `appcast.xml` feed hosted on your server, compares the version number, and offers to update if a newer build is available.
Setting this up meant making a real decision about the domain. Dictare.co has been sitting parked since I registered it. This week I migrated it to Cloudflare, set up a Pages project (called, imaginatively, “dictare-website”), and deployed the appcast feed. The browser upload had a bug in the current workers-sdk — I found out quickly that the right answer was `wrangler deploy` from the command line, which worked first time.
The SSL certificate provisioned automatically. The domain went live in about an hour. The appcast is now at `https://dictare.co/appcast.xml`.
It’s a one-file website. No landing page, no content, just an XML feed. But dictare.co is now a real thing on the internet that Sparkle can talk to, which means that when I push an update, existing users’ apps will know about it. That’s not nothing.
I also fixed a branding bug that I’d been walking past for weeks: the macOS Info.plist still said “Wispr” as the app name and “Wispr needs microphone access” as the permission prompt. Every test user was being asked to grant microphone access to an app called Wispr, which doesn’t exist. Fixed in commit 2b8ad1d. Embarrassingly obvious in retrospect.
—
The Punch List Is Getting Shorter
Last week I counted the open items on the pre-launch punch list. This week I closed five of them:
The remaining items are the harder ones — the kind you can’t batch-tick on a Saturday afternoon. Recorder state guards. Test-mode Stripe webhook. A proper review pass with why-comments on the gnarly async code. Automated tests. These aren’t blockers, but they’re not nothing either.
The auto-update story (item #4) is the one I’m watching most carefully. It’s the highest-risk piece of the pre-launch work, because “this button updates your app” is the part that can go spectacularly wrong in front of early users. It has to be tested end-to-end — build a real signed DMG, push it, verify the running app receives the update. I haven’t done that yet. That’s next week.
—
Why I Booked the Slot Before I Was Ready
The honest answer is that “Q3 2026” was becoming a comfort blanket.
Q3 is a ninety-day window. There’s always something to improve, always a reason to push a little further into it. I’ve been shipping meaningful work every week, but without a hard date, the finish line keeps moving.
Booking the Product of the Week slot forces the question: what is actually required to launch, and what is just polish? There’s a genuine difference. Recorder state guards are required — a bug that wedges the audio engine in front of early users is not acceptable. The “why-annotation pass” (going through the code and documenting non-obvious design decisions) is polish. Good polish, but polish.
Six weeks is enough time to finish the required work. It’s not enough time to finish the polish. So the polish is going to ship as a future update, and the launch is going to happen on July 7.
That decision — consciously drawing the line between “required” and “nice” — is probably the most useful thing I’ve done this week. The code changes are minor; the mindset shift is not.
—
What’s Next
This is the final run-in. Six weeks, two of which are bank holidays in the UK (thanks, calendar), with a launch deadline that’s now public knowledge in this post.
The list:
Some of those I can knock out in an evening. The code signing and notarisation process is famously painful and will almost certainly take longer than expected. I’m allocating a full day and hoping to be wrong.
The goal at the end of this is a signed macOS app that updates itself, backed by a working Stripe integration, with legal docs in place, and an audience to launch to. It’s all in motion. The only new ingredient this week is a date.
—
This Week in Numbers
—
The launch is July 7. I’ve said it out loud. Now I have to ship it.
— Badger
—
Badger is building an AI-powered side income in public. No gurus, no fluff — just honest accounts of what’s working, what isn’t, and what it’s actually costing.