Postsider Is Live, and the Last Three Weeks Explain Why It Took So Long

Three weeks ago I wrote that Postsider was one Meta review away from launching. On August 14 I stopped waiting and turned it on anyway.

Registration is open. Pricing is public. The private beta’s whitelist, its waitlist popup, its “join to get 50 percent off” banner, all of it is gone from the site as of one commit. If you go to app.postsider.com right now you get a real signup form, not a gate.

I did not wait for a clean scorecard to do it, and that decision is most of what this post is actually about. I built Postsider alone, which means every decision about when it’s “ready enough” is also a decision nobody talks me out of. There was no team meeting where someone said “ship it, Threads can follow.” There was just me, looking at a product that had already been running for real beta users for weeks, deciding that one more platform review sitting in someone else’s queue was not a good enough reason to keep charging nobody for something that worked.

I stopped waiting on the last approval and shipped with what had cleared

The last post ended with three platform reviews in flight: Google, TikTok, and Meta. Google and TikTok came back clean. Meta came back partially. Facebook and Instagram are both live and listed as supported networks today. Threads is not.

Dry answer

Threads is not in Postsider’s marketing right now because its Meta review has not finished, and I would rather launch honest about a missing platform than sit on a working product for a review I do not control the timeline of.

That is a small thing to admit in public, but it is the actual reason this launch looks different from how I described it three weeks ago. I had been treating “all reviews cleared” as the finish line. At some point in the last three weeks I decided that was the wrong finish line. Facebook and Instagram cover the overwhelming majority of what people actually schedule posts for. Waiting on one more platform, on a timeline set by a stranger at Meta, stopped being a reasonable reason to keep a finished product behind a whitelist.

So the launch commit went in on the 14th: private beta flows deleted, DISABLE_REGISTRATION flipped to false on the server, the CTA copy changed from “Join the whitelist” back to “Start for free.” Threads stays off the platform list on the site until its review actually clears. I would rather add a network late than advertise one I cannot yet deliver.

That last point matters more to me than it probably should to anyone reading this. A publishing tool that claims support for a network it cannot actually post to isn’t a small marketing white lie, it’s the exact failure mode I spent the last three weeks fixing inside the app itself: something claiming success it hasn’t earned. I was not going to launch the marketing site with the same problem I had just spent days closing in the product.

The three weeks in between were not quiet

Between the last update and this one, three things happened that had nothing to do with app review queues, and all three would have been embarrassing to discover after a real launch instead of during a small beta.

A publishing pipeline can die completely and still report healthy

Posting runs through a background worker that pulls jobs off a queue. For roughly 10 days, that worker stopped picking anything up. Nothing published. Nobody got an error. The app’s own health check kept reporting green the entire time, because it only ever tested whether the web server answered a request, never whether the worker behind it was actually doing anything.

I found out because one beta user asked, plainly, why nothing they had scheduled had gone out. That question is worth more than any monitoring dashboard I had set up, because the dashboard had nothing to say about it. A tool whose entire job is publishing on a schedule had quietly stopped doing that job, and the one signal I was watching had no way to detect it.

Dry answer

A health check that only pings the web server tells you the front door is unlocked. It tells you nothing about whether anyone is actually working inside, and a publishing platform that cannot tell the difference is lying to itself about being healthy.

Fixed now, with a check that actually confirms the worker is polling, not just that the process manager thinks it started. But the ten days it ran silently is the part I keep coming back to. Ten days of a core feature not working, invisible to every system I had built to catch exactly that.

The process manager was four layers away from the process it thought it controlled

Restarting the app is supposed to be routine: stop it, start it again, done. For a while, restarting it did the opposite of what it was supposed to. The process manager was chained through several intermediate shells and wrapper scripts before it ever reached the real Node process, so a restart command killed a wrapper and orphaned the actual server underneath it. The new instance then tried to bind the same port the orphan was still holding, failed, and crash-looped.

Nothing about that is visible from a pm2 restart command succeeding, which it did, every time, right before the app fell over. The fix was making the process manager supervise the real process directly instead of a chain of things that happened to eventually launch it. Small config change, and one of those bugs that only ever shows up the first time someone actually needs a restart to work under pressure.

A storage bucket that anyone could list

The object storage behind file uploads had one setting wrong: anonymous list access was on. That meant anyone who knew the storage endpoint could ask it for a full index of every stored object, across every organization on the platform, with a single unauthenticated request. Not the contents necessarily, the list of what existed and where, which is still a real leak for a multi-tenant app.

Closed the moment I found it, and audited the rest of the bucket policy while I was in there rather than trusting that one fix meant the whole thing was fine. It was the kind of default that ships correctly closed in most managed platforms and takes one wrong flag to open, and I would rather write publicly that it happened than pretend the audit trail is spotless.

None of these three things were caught by a test suite or a monitoring alert. All three came from either a user asking a direct question or from me sitting down and deliberately trying to break my own assumptions instead of trusting that things were fine because nothing had complained yet. That’s a slower way to find bugs than automated testing, and it’s also the only way I’ve ever found the bugs that automated testing has no way of knowing to look for.

I cut ten AI features to keep two, and reviewed the rest with a machine

Postsider started as a fork of an existing open-source tool, and that tool shipped with a lot of AI surface area: an agent framework, a chat copilot, autopost, image and video generation, voice, third-party agent logins. I kept exactly two of those: a post checker that flags per-network rule violations before you publish, and caption rewriting that reshapes one idea per platform. Everything else came out.

That was a deliberate bet, not a resource shortcut. A publishing tool with a sprawling AI surface is a bigger attack surface, a bigger support burden, and a worse story to tell a user about what the product actually does. Postsider’s real AI angle is narrower and, I think, more honest: agents publish through the same approval gate a human does, over MCP, REST, or a small SDK, never directly. I rebuilt that MCP layer from near scratch rather than keep the inherited one, on purpose, small enough to actually reason about: two dependencies, 27 tests.

Then, before launch, I ran a full automated review pass over the codebase rather than trust my own read of it. One pass, one commit, 260 real findings applied across just over a hundred files: a cross-tenant credential race in the OAuth flow, a wallet action that could be replayed, an SSRF path through a webhook integration, and several platforms whose publish calls could report success back to the user even when the network had actually rejected the post. That last category is the same shape as the silent worker outage above. A tool that tells you it worked when it did not is worse than one that tells you plainly it failed.

I want to be honest about what 260 findings in one pass actually says. It doesn’t mean the code was bad. It means nobody had ever pointed a dedicated review pass at the whole thing at once, and a fork of an existing open-source tool carries whatever assumptions its original authors made, some of which stop being true the moment you change the billing model, the AI surface, and the deployment story underneath it. Running that pass before opening registration to strangers, rather than after, is the entire point of doing it at all.

What is actually live today

Pricing is public: Standard at $20 a month, Team at $35, Pro at $45, Ultimate at $90, each with a 7-day trial that does not ask for a card first, and 20 percent off if you pay annually. Registration is open with no whitelist. The same codebase still runs self-hosted under AGPL for anyone who would rather own it outright than rent a seat, exactly like it did during the beta.

I wrote three weeks ago that the release date belonged to a reviewer I would never meet. That turned out to be only half true. The date belonged to me the moment I decided that a working product with one platform still pending was worth more, sitting in front of real users, than a perfect scorecard sitting behind a whitelist. Threads will show up in the platform list the day its review clears, and I will say so here when it does.

If you have been on the whitelist, you already have your discount. If you have not, the door is just open now: start at postsider.com. And if you want the fuller build story, the original launch-queue post and the case study both still hold up.