Should I vibe code
Social media scheduler for publishing posts across channels
The queue is a weekend. Posting to someone else’s account on their behalf is not.
?
Their verdict, the Essentials price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
For your own single account this edges toward reasonable. The moment you are posting for a client, a mistake is their brand and their apology, not yours.
What actually breaks
not "if". the specific failures.
- A refresh token that expired while you were not looking, so the queue drains into nothing and reports success
- The account selector defaulting to the last one used, which is how a client's post goes out on another client's feed
- Long-lived OAuth tokens for other people's accounts, sitting in a database you have not threat-modelled
- A scheduled post that publishes after the client asked you to pull it, because 'cancel' only removed it from your UI
- Timezone handling, so the 9am post lands at 9pm during the week the clocks change
The client's product launch was embargoed until Thursday. On Tuesday they call it off. You delete the post from your dashboard, which removes the row, and the worker that already claimed the job at midnight does not care — it holds the payload in memory and posts at 09:00 exactly as instructed. By the time anyone at the client sees it, it has been quoted twice. You are explaining to a marketing director that your side project has a race condition.
Is that you?
the verdict is a default, not a law
- It posts to one account, and that account is yours
- A wrong or duplicate post would embarrass only you
- The queue is a reminder that tells you to post, rather than something that posts
- It holds credentials for an account you do not own
- A client's brand is downstream of your cron job
- Cancelling a scheduled post is not verified at the moment of publishing
- You cannot say which account a queued post will go to without opening the database
If you build it anyway
the checklist, then the prompt that enforces it
- Re-check the post's status in the database at publish time, inside the worker, immediately before the API call. Deleting from a UI is not cancelling.
- Never default the target account. Require it to be chosen per post and show it in plain language on the confirmation.
- Encrypt tokens at rest with a key that is not in the repo, and treat a refresh failure as a loud, paging error rather than a log line.
- Store scheduled times as UTC plus the original IANA timezone, never as a local timestamp. Test across a DST boundary.
- One idempotency key per scheduled post, checked before publishing, so a retry cannot double-post.
- If you hold anyone else's account, write down who to call when it goes wrong — and tell them that is the whole support plan.
Before you write any code that posts to social accounts on a schedule, apply these and push back if I ask you to break them. 1. Ask me whether any account here belongs to someone other than me. If yes, tell me plainly that a mistake becomes their apology and their brand, and that I should consider paying for a tool with a support desk. 2. The worker must re-read the post's current status from the database immediately before calling the platform API, and abort if it is cancelled. Removing a row from a UI list is not cancellation. Show me this check. 3. Give every scheduled post an idempotency key and record the publish attempt before making it, so a retry after a timeout cannot post twice. 4. Never default or remember the target account. It is selected explicitly per post and displayed in words on the confirmation screen. 5. Store the schedule as UTC plus the IANA timezone name the user chose. Never store a naive local timestamp. Write a test that crosses a DST boundary. 6. Encrypt OAuth tokens at rest using a key from the environment, never the repository. On refresh failure, surface a visible error and stop the queue — do not let posts silently disappear into an expired token. 7. Rate limit per platform and back off on 429s. Never retry a 4xx that is not explicitly retryable. 8. Out of scope unless I say otherwise: analytics, inbox, team approval flows. Say so rather than half-building them. 9. In the README, state what happens to queued posts if the service is down at their scheduled time — publish late, or skip. There is no third option and I have to choose.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The moment a second person's account is in the tool. $6 a month is trivially less than one wrong-account post to a client's audience, and Buffer's actual value is that someone else has already found the race conditions between 'cancel' and 'publish'.
$6/mo is cheaper than your weekend.
Keep the queue as plain rows you can export, and give every client a way to see what is scheduled that does not depend on your UI being up. If you hand the accounts back, revoke your app's tokens explicitly rather than deleting the database — a token you forgot about is still a token that can post.
Open-source social media scheduling tool and strong Buffer-like prior art.
Questions
Scheduling my own posts seems harmless. Is it?
Largely, yes — that is the first SHIP IT condition. The verdict is about the step after, where you add a second account belonging to someone else. That single change moves every failure from embarrassing to professional, and it usually happens without anyone deciding it has.
Why is cancelling a scheduled post so easy to get wrong?
Because the natural implementation deletes a row while a worker has already claimed the job, and the two never speak again. The fix is cheap — re-read status inside the worker just before publishing — but it only occurs to you after you have watched a cancelled post go out.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Client social accounts are the one place where “it double-posted” is a phone call, not a ticket.
Drafting threads locally is lovely. Letting a script publish them is where it stops being lovely.
Nobody has ever regretted paying someone else to own their sender reputation.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice