Can BulkPublish be vibe coded?
Queue a spreadsheet of posts once and let it publish across every connected social account
The part people picture is a focused implementation: a list of posts, a timer, one API call each. The part that eats the next six months is everything after the first successful post · staying authenticated to a dozen networks, learning each one's media rules the hard way, publishing that reports success and then quietly fails minutes later, retries that must never post twice, and a review process before some networks will accept a post at all. Build it for two accounts you control and it works. Build it for every network on the marketing page and you have taken a job.
Jump to the build brief ↓Legacy-calibrated assessment
Checked Aug 2026
What you pay today, before any DIY hosting
high editorial confidence
Tracked separately from the pricing check
Buildability by layer
Screens, forms, and focused interactions
The repeatable job the product performs
Availability and legality of required data
Uptime, queues, support, and maintenance
Security, compliance, and user confidence
The achievable core
- Import a spreadsheet of captions and images, point each row at one or more connected accounts, and let it publish on schedule with a log of what landed.
- Draft, queue, and track content for the few networks you actually use.
- A responsive interface with real empty, loading, success, and error states.
The parts a prompt cannot buy
- staying connected · networks expire your auth and someone has to notice
- knowing a post is malformed before the network rejects it, not after
- an honest publish status when a network accepts the upload and fails minutes later
- analytics pulled back per post
- Connectors, OAuth flows, and vendor API changes require constant upkeep.
- The last 20 percent is sync, migration fidelity, speed, and edge cases.
Build, switch, or keep paying
Narrower, with trade-offs
Import a spreadsheet of captions and images, point each row at one or more connected accounts, and let it publish on schedule with a log of what landed.
Use the build brief ↓3 checked options
- Postiz ↗The broadest open scheduler here; free means running PostgreSQL, Redis, Temporal and your own platform credentials.
- Mixpost Lite ↗A polished single-user scheduler with queues and basic analytics; the team features live in the paid edition.
- Publer Free ↗Three non-X accounts and ten queued posts each, with a bulk CSV importer that is the closest free match for the actual job.
$13.99/mo
Because a scheduler is only worth anything when it is boring, and a self-built one stops being boring the first time a token expires overnight or a network changes its video rules without telling anyone. People pay so that maintenance is somebody else's Tuesday.
Visit BulkPublish ↗Why people still pay
Because a scheduler is only worth anything when it is boring, and a self-built one stops being boring the first time a token expires overnight or a network changes its video rules without telling anyone. People pay so that maintenance is somebody else's Tuesday.
Connectors, OAuth flows, and vendor API changes require constant upkeep.
The last 20 percent is sync, migration fidelity, speed, and edge cases.
Reliability at the vendor's scale is an operations problem, not a prompt.
The brief
Context, requirements, acceptance criteria, non-goals, and the full production standard — as Markdown, ready for any coding agent.
Build brief — a focused alternative to BulkPublish
Context
BulkPublish — Queue a spreadsheet of posts once and let it publish across every connected social account. It currently costs $13.99/mo.
The part people picture is a focused implementation: a list of posts, a timer, one API call each. The part that eats the next six months is everything after the first successful post · staying authenticated to a dozen networks, learning each one's media rules the hard way, publishing that reports success and then quietly fails minutes later, retries that must never post twice, and a review process before some networks will accept a post at all. Build it for two accounts you control and it works. Build it for every network on the marketing page and you have taken a job.
This brief describes a focused, single-operator replacement for the part of BulkPublish that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.
What you are building
Import a spreadsheet of captions and images, point each row at one or more connected accounts, and let it publish on schedule with a log of what landed.
Draft, queue, and track content for the few networks you actually use.
A responsive interface with real empty, loading, success, and error states.
Requirements
Functional
Somewhere always on for the schedule to fire.
Somewhere to keep the posts and the media.
Patience for the retry and duplicate-post edge cases.
Data and integrations
A developer app and API credentials per network (several need review before they will publish anything).
Each of these needs a real account, credential, or quota. Set them up before writing feature code.
Non-functional
Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
Security: server-side secrets, validated input, and no credentials in the client bundle.
Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
Portability: the operator can export their data and leave without losing it.
Implementation brief
Build me a personal bulk social scheduler to replace BulkPublish. Requirements:
Python 3.12 + FastAPI + SQLite, Jinja templates, no JavaScript framework.
One process on an always-on box, APScheduler ticking once a minute.
Two networks only: Mastodon (access token) and Bluesky (app password).
One small module per network behind a single publish(post, account)
function so a third is addable later. Scaffold nothing I do not use.
The main screen is a CSV importer. Columns: caption, image, send_at,
accounts. Show me every parsed row with a per-network character count and
a red flag on anything too long or missing a file, and import only the
rows that pass.
Rows with no send_at fall into posting times I configure per account
(weekdays 09:00 and 17:00 in my timezone) and take the next free one.
Each tick picks up due rows one at a time and flips the row to "sending"
in its own transaction before any network call, so a crash or a double
tick can never post the same row twice. Then "sent" with the live post
URL, or "failed" with the error text. Three retries, backing off, and
never a retry once a send is confirmed.
Images copied into media/ beside the database, checked for type and size
at import, removed 90 days after the row sends.
A history page: last 200 rows, status, error, link to the live post, and
a retry button.
Out of scope, and say so plainly in the README: X, Instagram, LinkedIn
and TikTok (paid, approval-gated or review-gated APIs), analytics,
approvals, and more than one user.
README covers getting a Mastodon token and a Bluesky app password.
Secrets in .env, localhost only, no accounts, no telemetry.
Delivery standard
Inspect the repository first, then write a short implementation plan before writing code.
Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
Add structured logs around every external call and return actionable errors without leaking sensitive details.
Write unit tests for the core logic and one automated test of the main user journey.
Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.
Acceptance criteria
A clean install starts the app using only the README and .env.example.
The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
Tests, type checking, linting, and a production build all pass with no ignored failures.
No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.
Non-goals
Do not build these, and do not claim to have replaced them:
Staying connected · networks expire your auth and someone has to notice.
Knowing a post is malformed before the network rejects it, not after.
An honest publish status when a network accepts the upload and fails minutes later.
Analytics pulled back per post.
Approvals, teams and multiple client workspaces.
The platform review process that gates posting on some networks entirely.
What you still own after launch
Secure credentials, rotate secrets, and handle provider rate limits.
Run migrations, backups, restores, and dependency updates.
Test the critical journey after every model, API, or hosting change.
Monitor failures and fix the edge cases a first prompt will miss.
Maintain every third-party integration as APIs and OAuth rules change.
Risk
Operational risk. The code is achievable; dependable data, integrations, and ongoing operations are the real cost.
Editorial confidence in this assessment: high. No reviewed project implementation is linked yet.
Existing alternatives
Before building, compare these checked options:
Postiz — The broadest open scheduler here; free means running PostgreSQL, Redis, Temporal and your own platform credentials
Mixpost Lite — A polished single-user scheduler with queues and basic analytics; the team features live in the paid edition
Publer Free — Three non-X accounts and ten queued posts each, with a bulk CSV importer that is the closest free match for the actual job
Prior art
Working open-source software you can read, fork, or borrow from before starting:
Postiz — Open-source multi-network scheduler · the most complete working example to read before starting
Mixpost — Self-hosted scheduler with a smaller, more readable codebase than the alternatives
Generated by Can It Be Vibe Coded? · Full report: https://www.canitbevibecoded.com/bulkpublish
You still own the product
- Secure credentials, rotate secrets, and handle provider rate limits.
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.
- Maintain every third-party integration as APIs and OAuth rules change.
Projects built from this idea
No reviewed implementation has been linked for BulkPublish yet. A submission is evidence for review, not automatic proof that the whole product was replaced.
Built a version of BulkPublish?Submit the project as evidence for this report.
Open-source prior art
Before you start
Can BulkPublish be vibe coded?
Partly, if you narrow it. The part people picture is a focused implementation: a list of posts, a timer, one API call each. The part that eats the next six months is everything after the first successful post · staying authenticated to a dozen networks, learning each one's media rules the hard way, publishing that reports success and then quietly fails minutes later, retries that must never post twice, and a review process before some networks will accept a post at all. Build it for two accounts you control and it works. Build it for every network on the marketing page and you have taken a job.
What can an AI coding agent reproduce from BulkPublish?
Import a spreadsheet of captions and images, point each row at one or more connected accounts, and let it publish on schedule with a log of what landed. Draft, queue, and track content for the few networks you actually use. A responsive interface with real empty, loading, success, and error states.
What will a DIY BulkPublish replacement still be missing?
staying connected · networks expire your auth and someone has to notice; knowing a post is malformed before the network rejects it, not after; an honest publish status when a network accepts the upload and fails minutes later; analytics pulled back per post; Connectors, OAuth flows, and vendor API changes require constant upkeep.; The last 20 percent is sync, migration fidelity, speed, and edge cases.
What do I still own after building a BulkPublish alternative?
Secure credentials, rotate secrets, and handle provider rate limits. Run migrations, backups, restores, and dependency updates. Test the critical journey after every model, API, or hosting change. Monitor failures and fix the edge cases a first prompt will miss. Maintain every third-party integration as APIs and OAuth rules change.