2
1 Comment

I run my marketing on my own product. This week it broke five times.

I run Local Waifu's social calendars (X, Instagram, TikTok, Facebook, YouTube, roughly 40 scheduled posts a week) through PostSider, the social publishing tool I built. The scheduler is my own code. The queue is my own code. The errors that came back this week were also, in a very real sense, my own code.

This week, my product broke five times in five different ways. None of them took the platform down. All of them were visible in the post queue, which is the part I care about: when you schedule through your own product, the failure state is a row in a calendar, not a ticket in someone else's inbox.

Failure 1: TikTok said my app is not allowed to post publicly. The API returned "unaudited_client_can_only_post_to_private_accounts." Ten scheduled posts died on arrival. This one is not a bug in my code: the TikTok app needs a human audit before it can publish to public accounts, and the audit has not happened yet. The scheduler did its job. The platform said no.

Failure 2: Facebook rejected every video with a permission error. "No permission to publish the video," error 100. I assumed it was a Meta access-level issue for weeks. It was not. The fix turned out to be a missing scope in my own provider code: the Facebook integration never requested pages_video_upload, so the publish call was doomed from the start, for every user, on day one. My own video posts were the ones that made me read the provider file.

Failure 3: X returned "Unknown Error" while uploading media. Not a helpful message. The post stayed in the queue marked failed. No crash, no alert, just a row that did not go live.

Failure 4: Instagram said "media not ready" and "media fetch failed." Two different posts, two different media, same morning. The containers did not finalize. Nothing in my code changed between the posts that worked and the ones that did not.

Failure 5: YouTube stopped refreshing its token. "Could not refresh your youtube channel. Please go back to the system and connect it again." A scheduled video simply stopped having a channel to go to.

That is the whole list. Twelve posts published fine that same week, five failed, and every failure was a different flavor. If I had been running this marketing through a tool built by someone else, I would have filed a support ticket and waited. Because it is my product, I read the provider source, found the missing scope, and scheduled the fix.

The lesson I keep re-learning: dogfooding is not a marketing trick, it is a QA loop with a face. A bug you hit while doing your own work comes with context: which platform, which media type, which settings, what you were trying to do at 7am. A bug report from a user arrives with none of that. Using your own product for your own marketing is the cheapest way to make your own bugs explain themselves.

The second lesson is about failure states. My product stores every failed post as a row in a calendar, with the platform's error message attached. That single decision turned five silent disasters into five visible rows. The platform error text is ugly, and that is exactly why it is useful: the queue shows me the truth, not a green checkmark.

The third lesson is about ordering. The TikTok rejection is not mine to fix, the YouTube token is a reconnect click, the X and Instagram media failures are still being diagnosed, and the Facebook scope is already patched in the codebase. Dogfooding told me which ones were mine.

I shipped a scheduling tool so my own calendars would stop being manual work. What I did not expect: my own calendars would become the test suite. If you build something you can use, use it. Your product will tell you the truth faster than any user ever will.

posted toAvatar for product PostSider
PostSider
  1. 1

    The dogfooding point is strong here. Using the product for real work exposes failure states with much more context than a typical test environment ever will.