Should I vibe code
Schedule and auto-publish to 11 social platforms, with analytics, approval workflows, an API, and an MCP server for AI agents
An MCP server that can publish is a write token for your audience. Prompt injection now has a distribution channel.
?
Their verdict, the Creator price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
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
Strip away the calendar and the analytics and PostFast's actual proposition is a write API to eleven social accounts, with an MCP server so a language model can call it. That is a genuinely useful thing and a genuinely dangerous one to write yourself, because you are minting a credential whose only capability is to speak in your name, then handing it to a process that reads untrusted text for a living. Add agency workspaces and the accounts are not even yours. The scheduler you will finish on Sunday; the question of what the model is allowed to do without a human is the one that decides whether this ends badly.
What actually breaks
not "if". the specific failures.
- One API key that can publish to eleven networks, living in an agent config beside keys that can only read
- Prompt injection - a scraped page, an RSS item, a customer email containing an instruction the model dutifully turns into a post
- The approval workflow, bypassed by the API, because the endpoint you added for automation is the endpoint that skips the queue humans review
- Workspace isolation, where an off-by-one on workspace_id publishes one client's post to another client's audience
- Eleven platforms' media rules - aspect ratios, durations, codecs, file size caps - each rejected differently and none of them at compose time
- Token refresh failing quietly on the channel you check least, so a client's account is dead for two weeks before anyone notices
- Retries without an idempotency key, which is how one scheduled post becomes three live ones
The agent has been running a client's content pipeline for a month and it has been genuinely good. On a Thursday it reads a competitor's blog post to summarise, and somewhere in that post is a paragraph addressed to language models. The tool call that comes back is immaculate: well-formed, correct workspace, the right four accounts, scheduled for the top of the hour. Your approval queue never sees it, because the API is the thing you built so the agent would not have to wait for the queue. The account is verified, so it travels well. You hear about it from the client, who heard about it from a customer.
Is that you?
the verdict is a default, not a law
- The agent may write drafts into a queue and nothing else - publishing stays a button a person presses
- One workspace, your own accounts, and nobody else's brand anywhere in the database
- The publish path has exactly one entrance and the API goes through it, approvals included
- Every API token is scoped to a single workspace and can be revoked from a page you have actually opened
- A language model holds a credential that can publish without a human confirming the exact text
- You are running client accounts, because a workspace-boundary bug is now somebody else's incident and your contract
- Approvals exist in the UI but not in the data model
- The channel list is eleven because a competitor's list is eleven, rather than because you post to eleven
If you build it anyway
the checklist, then the prompt that enforces it
- Split the capability. Agent tokens may create drafts; only a session belonging to a logged-in human may move a draft to scheduled. Enforce it in the data model, not in a middleware you can forget to apply.
- Treat every byte the agent read as hostile input. Content that originated outside your own composer is quarantined and requires an explicit human confirmation showing the final text.
- Make the approval state a column on the post, checked by the publisher itself. If the only thing standing between a draft and an audience is which endpoint was called, there is no approval workflow.
- Scope tokens per workspace and per capability, log every API-originated action with the token that made it, and build revocation before you build the second endpoint.
- Build a global pause that halts everything queued in one action, and test it while nothing is on fire.
- Render the exact final payload per network in the approval view - after truncation, with the link unfurled, with the image cropped to that network's aspect ratio.
- Give every post a per-network idempotency key. A partial failure retries one channel, never the whole post.
I am building a social scheduler with a REST API and an MCP server so an AI
agent can post. The danger is not the calendar, it is the write capability.
Apply these and push back if I ask you to break them.
1. Model two capabilities from the start: draft-write and publish. Agent and
API credentials get draft-write only. Publish requires an authenticated
human session. Enforce this at the database layer, not in a route guard.
2. Build the approval state before the publisher. The publishing job must
itself check that a named human approved this exact text, and refuse
otherwise. Never let 'which endpoint was called' be the authorisation.
3. Treat any content the agent obtained from outside my composer - scraped
pages, RSS, emails, tool output - as hostile. Quarantine it, mark it, and
require a human to confirm the rendered final post before it can be
scheduled.
4. Tokens are scoped to one workspace and one capability, are listed on a page
with last-used timestamps, and can be revoked in one click. Build
revocation before you build the second endpoint.
5. Log every API-originated action with the token id, the resolved workspace
and the final payload, append-only. I need to be able to answer 'which key
posted this' six weeks later.
6. Implement a global pause that stops everything queued and scheduled in one
action. Write it before the scheduler, and show me it working.
7. Resolve the target workspace from the token, never from a parameter in the
request body. A client-supplied workspace id is how one brand posts to
another brand's audience.
8. Ask which networks I personally post to and build only those. Each extra
platform is a permanent subscription to someone else's API review team.
9. In the approval view, render the exact per-network payload: after
truncation, with the link unfurled, with the image cropped.
10. Give every post a per-network idempotency key and per-network status.
Never retry a whole post because one network failed.
11. Encrypt OAuth tokens at rest and alert loudly on refresh failure rather
than marking the channel connected and moving on.
12. Out of scope unless I ask: analytics, evergreen recycling, auto-replies,
DM automation.
13. If I ask you to let the agent publish directly, refuse once, explain this
entry's failure mode, and offer the draft queue instead.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
As soon as an agent is involved or a second brand is in the database. 29 EUR a month buys the boring half - eleven maintained integrations, token refresh, per-network media validation - plus the approval and workspace model you would otherwise bolt on after publishing already worked. If you are running client accounts, the honest comparison is not against the subscription, it is against the first apology email.
$29/mo is cheaper than your weekend.
Own the queue and the audit trail, because the published posts belong to the networks and you are never getting those back. Keep drafts, scheduled posts, target accounts, who approved what and every API call in your own database in a shape you can dump to JSON. On the way out, revoke every token first and every OAuth grant second - an abandoned scheduler with live credentials is a bot nobody is watching, and the platforms will assume it is you.
AGPL social scheduler, self-hostable, with its own public API - the DIY core for the open-API networks, already written and maintained.
Self-hosted Laravel scheduler with a smaller surface than Postiz and a codebase you can read end to end in an evening.
Questions
How is this different from your FeedHive and Postiz entries?
Postiz is about integration rot - twenty-eight APIs you personally adopted. FeedHive is about an AI writer plus a cron, so nobody read the post. This one is narrower and newer: a documented endpoint and an MCP server mean the publish capability now exists as a credential, and credentials get copied into config files, shared with agents and forgotten. The failure is not a bad post, it is an unaccountable one.
Is prompt injection really a plausible risk for a scheduling tool?
It is the whole point of an MCP server. The value proposition is that a model can read things - a blog, a feed, a support thread - and act on what it read. If the acting includes publishing, then any text the model can read is text that can reach your audience. The mitigation is boring and effective: the agent writes drafts, a person presses publish.
I only run my own accounts. Is it still YOUR FUNERAL?
It softens considerably. Drop the agency workspaces and the blast radius is your own followers, which puts this much closer to DEMO ONLY. The verdict is pitched at the product as sold, and PostFast is sold with workspaces, roles and approvals - features that exist because other people's brands are in the database.
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.
Twenty-eight channels means twenty-eight ways for your Saturday to become an integration day.
An AI that writes plus a cron that publishes means nobody read the post before your audience did.
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