shouldivibecodeit

Should I vibe codeHypefury?

Draft and schedule text-led social posts with reusable queues

Hypefury had to drop Twitter. Your clone doesn't get a vote on that either.

?

Their verdict, the Essentials price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.

Can you build it?asked by canivibecodeit.com ↗KINDAweekend project · multi-day
?

Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.

Should you ship it?asked by usYOUR FUNERALit’ll work. then it’ll get you.

The honest answer

why the verdict is what it is

The scheduling is a cron job and a database table, and if that were the product this would be a cheerful entry. It isn't. The product is staying authorised: Meta's long-lived tokens die after sixty days unless something refreshes them in time, and LinkedIn only issues refresh tokens to approved Marketing Developer Platform partners, so an ordinary app means re-authorising by hand, forever, on a rolling clock you will forget about. Around that sit two things that publish without you — a retry that turns one timeout into two identical posts, and an evergreen recycler that pushes something you wrote in March into a Tuesday whose news you have not read. And then the argument that settles it: Hypefury itself dropped X rather than keep paying for the API. That is what a platform rug-pull looks like from the vendor's side of the table, and your version does not get a vote either.

What actually breaks

not "if". the specific failures.

  • Tokens, on a rolling sixty-day clock. Meta's long-lived tokens expire after sixty days and cannot be refreshed once they have, and LinkedIn hands refresh tokens only to approved Marketing Developer Platform partners — so a standard app is a calendar reminder you keep snoozing
  • Retries. The publish call times out after the post was actually created, the job runs again, and your followers get the same thing twice four minutes apart — with the delete being the part everyone notices
  • Evergreen recycling, which reposts March's confident opinion into a Tuesday you have not read the news for
  • The missing kill switch, because a global pause is not a feature anybody thinks about while building the part that posts
  • Schedule arithmetic: a queue configured for 9am that silently becomes 8am for half the year, and slots that stack up on the day the clocks change
  • Auto-appended follow-up comments still pointing at a landing page you took down in April
  • The refresh token in your database, which is a credential that posts as you with no password prompt and no second factor between it and your audience
  • The platforms themselves, without warning — Hypefury dropped X entirely rather than keep paying, and it was their business
and then, at 3am

The news breaks at half six in the morning and by seven the timeline is entirely one story. Your queue does not read the news. It fires at 07:15 with a bright line about morning routines, at 09:00 with a recycled post from March, and at 11:30 with an auto-appended plug for a course. You find out from a reply. There is no pause button — a pause button is not something you think about while building the part that posts — so you are in psql deleting rows from scheduled_posts while the worker keeps claiming them faster than you can, until you work out that the quickest way to stop your own software is to revoke its tokens. Getting those back takes most of the week, because the LinkedIn re-authorisation flow is the other thing you never automated.

Is that you?

the verdict is a default, not a law

ship it if
  • You press the button. A drafting tool that posts on demand is a completely different risk profile from one that posts while you sleep
  • It targets Bluesky only, which is the one platform here whose API is not gated behind partner approval and quarterly policy changes
  • Everything queued is reviewed the morning it goes out, by a person, with the option to bin it
  • You have a global pause you have actually tested, not one you believe exists
don’t ship it if
  • Anything publishes unattended while you are asleep or on a plane
  • Old posts are recycled automatically without a fresh human approval
  • The tokens belong to a client's accounts rather than your own
  • A VA or a ghostwriter also has access, because the credential is now shared and the audit trail is not
  • You could not stop every pending post inside thirty seconds, from your phone

If you build it anyway

the checklist, then the prompt that enforces it

  1. Give every scheduled post an idempotency key, store the platform's returned post id, and refuse to publish anything that already has one. Duplicate posts are the most common failure in this category and the easiest to design out.
  2. Build the global pause switch in the first commit, make it stop the worker rather than just hiding the UI, and test it before the first real post goes out.
  3. Run a token refresh job on a schedule well inside the sixty-day window, alert loudly when it fails, and put every account's expiry date on a page you actually look at.
  4. Encrypt tokens at rest, scope them to publishing only, keep one credential per account, and write down how you revoke all of them in one command.
  5. Never auto-publish recycled content. Recycling can queue a draft for approval; it cannot post one.
  6. Store schedules with an explicit timezone and compute run times in it, then test the day the clocks move in both directions.
  7. Log every publish with the account, the payload, the response and a link to the live post. When you are trying to work out what went out at 07:15, this is the only artefact that helps.
  8. Rate-limit yourself below each platform's published limits and back off on 429s. Getting your app throttled is recoverable; getting it flagged is not.
the guardrail prompt
I am building a social scheduler that publishes to Bluesky, Threads, LinkedIn
and Instagram on my behalf. Treat the credentials and the stop button as the
product and the calendar UI as decoration. Push back if I ask for these in a
different order.

1. First commit: a global pause that stops the publishing worker, callable from
   a shell, with no deploy and no UI. Then a test proving a queued post does not
   go out while it is on.
2. Then idempotency. Every scheduled post gets a key; a successful publish
   stores the platform's post id; a job that finds an id refuses to publish
   again. Write the test where the API times out after creating the post.
3. Then tokens. Encrypt at rest, one row per account, publish-only scopes, a
   refresh job well inside Meta's sixty-day window, an expiry dashboard. When a
   refresh fails at 2am it stops and alerts; it never retries with an old token.
4. Note in the README that LinkedIn issues refresh tokens only to approved
   Marketing Developer Platform partners, so re-authorisation may be manual and
   permanent. I need to know that before building on it, not after.
5. Then a one-command revoke-everything path for when I want out.
6. Schedules store an explicit timezone. Compute run times in it and include a
   test spanning a daylight-saving change in both directions.
7. Do not auto-publish recycled or evergreen content. Recycling may queue a
   draft for approval. If I ask for automatic reposting, say once that this is
   how old content lands in a news cycle nobody has read.
8. Log every publish — account, payload, response, live URL — before adding any
   analytics.
9. Rate-limit below each platform's documented limits and back off on 429s.
10. Out of scope on purpose: AI drafting, analytics dashboards, multi-user
    access. If I want a ghostwriter to have access, tell me that means a shared
    credential and design a separate account first.
11. Finally: tell me Hypefury is $6 a month per channel, and that the thing I am
    actually buying is someone else keeping up with four platforms' auth.
paste this before you build — not after something breaks31 lines · 2074 chars

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

just pay for it

At $6 a month for a channel, the arithmetic is not close. That is less than the value of the first evening you spend working out why LinkedIn stopped accepting your token, and Hypefury employs people whose actual job is to notice when Meta changes the rules again. Build the drafting tool if you enjoy it — the editor and the queue view are the fun parts and nothing bad happens in them. Rent the part that holds credentials and presses publish.

$6/mo is cheaper than your weekend.

your exit plan, if you already built it

Keep drafts and the queue as files — markdown for the posts, a CSV or JSONL of scheduled times — so the content survives independently of the scheduler. Published posts already live on the platforms and are the one thing you cannot lose. The step people skip is the shutdown: revoke every token before you delete the project, because an orphaned worker on a forgotten host with valid publish credentials is the worst possible way for a side project to end.

prior art · someone already did this
Postiz

Active open-source social media scheduling platform.

Mixpost

Self-hosted social publishing tool that already owns the OAuth token handling for each platform.

Questions

canivibecodeit says KINDA. Why harsher?

They are answering whether an agent can build a scheduler, and it plainly can — the queue, the editor and the calendar all come out working. Our question is what happens in month four, when a token quietly expires, a retry double-posts, or a recycled draft goes out on a bad morning. None of those are build problems. They are operating problems, and the operator is you, at whatever hour the cron fires.

Does it help that Hypefury dropped X?

It is the clearest possible illustration of the risk. A funded company with paying customers concluded that supporting one platform was no longer viable and removed it. Your version has the same exposure to the same decisions with none of the leverage, and the day a platform changes its terms you will find out from a support thread rather than from a partner manager.

What if I only post to Bluesky?

Then this gets considerably better. The AT Protocol is open, the auth does not require partner approval, and no product manager is deciding whether your access is strategic this quarter. You still want idempotency and a pause switch, because double-posting and bad-timing are protocol-independent, but the maintenance treadmill largely disappears.

did you build it?

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.

also on the regret index
MetricoolYOUR FUNERAL

Nobody is paying for your dashboard. They're paying for the number in it, and your chart interpolates the gaps.

SuperXYOUR FUNERAL

It holds the keys to your public voice. A retry loop at 3am posts the same thing eleven times.

Post BridgeYOUR FUNERAL

Every platform’s API breaks on a different Tuesday. That maintenance is the whole subscription.

last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice