Running several content pages by hand meant the same routine every day: open each page, write a caption, attach an image, publish, repeat. None of it was hard — it was just repetitive enough to be worth a weekend of building instead of a permanent Tuesday chore.
The architecture
Nothing exotic: a small desktop app with a simple interface, a local queue of scheduled posts, and a background worker that checks the queue on an interval and publishes whatever's due. Content gets prepared in batches — a week's worth of captions and images loaded in at once — and the bot just works through the queue on schedule.
- Queue — a simple local store of pending posts with their scheduled time
- Worker — a background loop that checks the queue and triggers publishing
- Interface — a lightweight desktop UI for loading batches and reviewing what's queued
- Logging — every publish attempt written to a log, success or failure
The rate-limit lesson
The first version published as fast as the queue allowed, which looked great for about ten minutes before hitting a wall. Publishing platforms rate-limit aggressively, and hitting that limit doesn't just slow you down — it can flag the account for review. The fix was embarrassingly simple in hindsight: add deliberate spacing between posts and a backoff delay whenever a request fails, instead of retrying immediately.
The afternoon-eating bug
The worst bug wasn't in the publishing logic at all — it was in how the interface managed its own layout. Two parts of the UI were fighting over the same screen region, so widgets would occasionally overlap or vanish depending on which part of the app loaded first. It looked like a scheduling bug for a long time before the real cause turned up: a layout conflict that had nothing to do with posting logic at all. The lesson: when something looks like a logic bug but behaves inconsistently, check the interface layer before the business logic.
Most automation bugs aren't in the clever part of the code. They're in the plumbing you assumed was already solid.
What changed after shipping it
The real win wasn't speed — it was consistency. Pages that used to get posted in bursts, whenever there was time, now publish on a steady schedule regardless of how busy the week gets. That consistency mattered more for reach than any individual post's quality.
Would I build it again?
Yes, but smaller. The first version tried to handle too many edge cases up front. A queue, a worker, and a log would have been enough for the first month — everything else got added only once a real need showed up.