Vibecode PostFast
track this build5 steps, step by step0%The core loop is the one every scheduler shares and it is genuinely one-shottable: a compose box, a slot queue, a cron tick, one adapter per network. Two things sit outside what a coding agent hands you in a session. The first is paperwork. Only Bluesky and Telegram give you working credentials on signup; the other nine of PostFast's eleven destinations wait behind Meta App Review for Instagram, Facebook, and Threads, a TikTok audit before an app may post publicly rather than to a private draft, YouTube's default 10,000-unit daily quota against 1,600 units per upload, approval flows at LinkedIn, Pinterest, and Google Business Profile, and X, where the free tier is capped tightly enough that real volume means paying. The second is video. Every platform enforces its own container, codec, aspect ratio, duration, and size rules, so anything past text and a JPEG turns into a transcode pipeline with somewhere to actually run the jobs and a retry story for the upload that dies at 90 percent. Build the text-and-image version for the two open networks in a sitting; the rest is review forms and a transcode queue.
You are building a lean indie version of PostFast. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # PostFast indie build ## Goal Build the smallest trustworthy replacement for the core PostFast workflow for one developer or a tiny team. ## Scope Compose posts into a slot-based queue, publish them on schedule to the open-API networks via per-network adapters, and expose the same queue over MCP so a coding agent can schedule too. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - nine of the eleven destinations, which need app review or a paid API tier rather than more code - pre-approved OAuth apps for Instagram, TikTok, YouTube, LinkedIn, Pinterest, and Google Business Profile - the video pipeline: per-platform container, codec, aspect ratio, duration, and size rules, plus async processing and the retries for when a large upload fails partway - token refresh and the steady patching as platform policies move - analytics, follower history, approval workflows, and per-client workspaces - the hosted API, MCP server, and n8n/Zapier/Make integrations that let an agent post for you If those capabilities are essential, use Postiz instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build me a personal social scheduler my coding agent can drive, to replace PostFast. Requirements: - Node + Express + better-sqlite3 on my always-on box. Two interfaces over one core: a localhost page (compose box, media attach, queue by send time) and a stdio MCP server via @modelcontextprotocol/sdk with create_post, list_posts, and delete_post, so Claude Code can schedule without me opening the page. - Open-API networks only: Bluesky (app password via @atproto/api), Mastodon (access token), Telegram channel (bot token). One adapter file per network, creds in .env. - For the gated platforms (Instagram, TikTok, YouTube, Facebook, Threads, LinkedIn, Pinterest, Google Business Profile) do not fight the APIs: at send time push me an ntfy.sh alert with the caption and media path and I post by hand. The README says plainly that these need reviewed developer apps, not more code. - Slot-based queue: posting times per weekday in my timezone, new posts take the next free slot or pin to an exact datetime; one post fans out to several networks with per-network text. - A node-cron tick every minute sends what is due, marks the row sending before it calls anything so a crash never double-posts, retries 3 times with backoff, then records sent or failed with the error. - Media in media/ beside the database, images resized per network with sharp. Video: accept MP4 only and check duration, aspect ratio, and size against each network's limits at attach time, rejecting with the limit in the message rather than fixing it. - A history page of the last 100 sends linking to the live posts. - Binds to localhost only. No accounts, no telemetry, everything stays on my box. - Out of scope: video transcoding, analytics, approval workflows, and workspaces. Do not build auth. - README: Bluesky app password, Mastodon token, Telegram bot token, wiring the MCP server into Claude Code, and a warning that social APIs drift and need patching. ## Required capabilities - OAuth/API access per social network - always-on box for the scheduler - database - media storage - ffmpeg and somewhere to run transcodes for anything past text and images ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a lean indie version of PostFast. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # PostFast indie build ## Goal Build the smallest trustworthy replacement for the core PostFast workflow for one developer or a tiny team. ## Scope Compose posts into a slot-based queue, publish them on schedule to the open-API networks via per-network adapters, and expose the same queue over MCP so a coding agent can schedule too. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - nine of the eleven destinations, which need app review or a paid API tier rather than more code - pre-approved OAuth apps for Instagram, TikTok, YouTube, LinkedIn, Pinterest, and Google Business Profile - the video pipeline: per-platform container, codec, aspect ratio, duration, and size rules, plus async processing and the retries for when a large upload fails partway - token refresh and the steady patching as platform policies move - analytics, follower history, approval workflows, and per-client workspaces - the hosted API, MCP server, and n8n/Zapier/Make integrations that let an agent post for you If those capabilities are essential, use Postiz instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build me a personal social scheduler my coding agent can drive, to replace PostFast. Requirements: - Node + Express + better-sqlite3 on my always-on box. Two interfaces over one core: a localhost page (compose box, media attach, queue by send time) and a stdio MCP server via @modelcontextprotocol/sdk with create_post, list_posts, and delete_post, so Claude Code can schedule without me opening the page. - Open-API networks only: Bluesky (app password via @atproto/api), Mastodon (access token), Telegram channel (bot token). One adapter file per network, creds in .env. - For the gated platforms (Instagram, TikTok, YouTube, Facebook, Threads, LinkedIn, Pinterest, Google Business Profile) do not fight the APIs: at send time push me an ntfy.sh alert with the caption and media path and I post by hand. The README says plainly that these need reviewed developer apps, not more code. - Slot-based queue: posting times per weekday in my timezone, new posts take the next free slot or pin to an exact datetime; one post fans out to several networks with per-network text. - A node-cron tick every minute sends what is due, marks the row sending before it calls anything so a crash never double-posts, retries 3 times with backoff, then records sent or failed with the error. - Media in media/ beside the database, images resized per network with sharp. Video: accept MP4 only and check duration, aspect ratio, and size against each network's limits at attach time, rejecting with the limit in the message rather than fixing it. - A history page of the last 100 sends linking to the live posts. - Binds to localhost only. No accounts, no telemetry, everything stays on my box. - Out of scope: video transcoding, analytics, approval workflows, and workspaces. Do not build auth. - README: Bluesky app password, Mastodon token, Telegram bot token, wiring the MCP server into Claude Code, and a warning that social APIs drift and need patching. ## Required capabilities - OAuth/API access per social network - always-on box for the scheduler - database - media storage - ffmpeg and somewhere to run transcodes for anything past text and images ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a production product version of PostFast. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== PRODUCT.md ===== # PostFast product brief ## Problem The core loop is the one every scheduler shares and it is genuinely one-shottable: a compose box, a slot queue, a cron tick, one adapter per network. Two things sit outside what a coding agent hands you in a session. The first is paperwork. Only Bluesky and Telegram give you working credentials on signup; the other nine of PostFast's eleven destinations wait behind Meta App Review for Instagram, Facebook, and Threads, a TikTok audit before an app may post publicly rather than to a private draft, YouTube's default 10,000-unit daily quota against 1,600 units per upload, approval flows at LinkedIn, Pinterest, and Google Business Profile, and X, where the free tier is capped tightly enough that real volume means paying. The second is video. Every platform enforces its own container, codec, aspect ratio, duration, and size rules, so anything past text and a JPEG turns into a transcode pipeline with somewhere to actually run the jobs and a retry story for the upload that dies at 90 percent. Build the text-and-image version for the two open networks in a sitting; the rest is review forms and a transcode queue. ## Product outcome Compose posts into a slot-based queue, publish them on schedule to the open-API networks via per-network adapters, and expose the same queue over MCP so a coding agent can schedule too. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - OAuth/API access per social network - always-on box for the scheduler - database - media storage - ffmpeg and somewhere to run transcodes for anything past text and images ## Explicit non-goals for v1 - nine of the eleven destinations, which need app review or a paid API tier rather than more code - pre-approved OAuth apps for Instagram, TikTok, YouTube, LinkedIn, Pinterest, and Google Business Profile - the video pipeline: per-platform container, codec, aspect ratio, duration, and size rules, plus async processing and the retries for when a large upload fails partway - token refresh and the steady patching as platform policies move - analytics, follower history, approval workflows, and per-client workspaces - the hosted API, MCP server, and n8n/Zapier/Make integrations that let an agent post for you ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees. ===== ARCHITECTURE.md ===== # Architecture ## Starting brief Build me a personal social scheduler my coding agent can drive, to replace PostFast. Requirements: - Node + Express + better-sqlite3 on my always-on box. Two interfaces over one core: a localhost page (compose box, media attach, queue by send time) and a stdio MCP server via @modelcontextprotocol/sdk with create_post, list_posts, and delete_post, so Claude Code can schedule without me opening the page. - Open-API networks only: Bluesky (app password via @atproto/api), Mastodon (access token), Telegram channel (bot token). One adapter file per network, creds in .env. - For the gated platforms (Instagram, TikTok, YouTube, Facebook, Threads, LinkedIn, Pinterest, Google Business Profile) do not fight the APIs: at send time push me an ntfy.sh alert with the caption and media path and I post by hand. The README says plainly that these need reviewed developer apps, not more code. - Slot-based queue: posting times per weekday in my timezone, new posts take the next free slot or pin to an exact datetime; one post fans out to several networks with per-network text. - A node-cron tick every minute sends what is due, marks the row sending before it calls anything so a crash never double-posts, retries 3 times with backoff, then records sent or failed with the error. - Media in media/ beside the database, images resized per network with sharp. Video: accept MP4 only and check duration, aspect ratio, and size against each network's limits at attach time, rejecting with the limit in the message rather than fixing it. - A history page of the last 100 sends linking to the live posts. - Binds to localhost only. No accounts, no telemetry, everything stays on my box. - Out of scope: video transcoding, analytics, approval workflows, and workspaces. Do not build auth. - README: Bluesky app password, Mastodon token, Telegram bot token, wiring the MCP server into Claude Code, and a warning that social APIs drift and need patching. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it. ===== AGENTS.md ===== # Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone. ===== MILESTONES.md ===== # Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations. ===== OPERATIONS.md ===== # Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted PostFast capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
# PostFast indie build ## Goal Build the smallest trustworthy replacement for the core PostFast workflow for one developer or a tiny team. ## Scope Compose posts into a slot-based queue, publish them on schedule to the open-API networks via per-network adapters, and expose the same queue over MCP so a coding agent can schedule too. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - nine of the eleven destinations, which need app review or a paid API tier rather than more code - pre-approved OAuth apps for Instagram, TikTok, YouTube, LinkedIn, Pinterest, and Google Business Profile - the video pipeline: per-platform container, codec, aspect ratio, duration, and size rules, plus async processing and the retries for when a large upload fails partway - token refresh and the steady patching as platform policies move - analytics, follower history, approval workflows, and per-client workspaces - the hosted API, MCP server, and n8n/Zapier/Make integrations that let an agent post for you If those capabilities are essential, use Postiz instead of pretending the gap is solved.
# Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs".
# Build plan ## Original build brief Build me a personal social scheduler my coding agent can drive, to replace PostFast. Requirements: - Node + Express + better-sqlite3 on my always-on box. Two interfaces over one core: a localhost page (compose box, media attach, queue by send time) and a stdio MCP server via @modelcontextprotocol/sdk with create_post, list_posts, and delete_post, so Claude Code can schedule without me opening the page. - Open-API networks only: Bluesky (app password via @atproto/api), Mastodon (access token), Telegram channel (bot token). One adapter file per network, creds in .env. - For the gated platforms (Instagram, TikTok, YouTube, Facebook, Threads, LinkedIn, Pinterest, Google Business Profile) do not fight the APIs: at send time push me an ntfy.sh alert with the caption and media path and I post by hand. The README says plainly that these need reviewed developer apps, not more code. - Slot-based queue: posting times per weekday in my timezone, new posts take the next free slot or pin to an exact datetime; one post fans out to several networks with per-network text. - A node-cron tick every minute sends what is due, marks the row sending before it calls anything so a crash never double-posts, retries 3 times with backoff, then records sent or failed with the error. - Media in media/ beside the database, images resized per network with sharp. Video: accept MP4 only and check duration, aspect ratio, and size against each network's limits at attach time, rejecting with the limit in the message rather than fixing it. - A history page of the last 100 sends linking to the live posts. - Binds to localhost only. No accounts, no telemetry, everything stays on my box. - Out of scope: video transcoding, analytics, approval workflows, and workspaces. Do not build auth. - README: Bluesky app password, Mastodon token, Telegram bot token, wiring the MCP server into Claude Code, and a warning that social APIs drift and need patching. ## Required capabilities - OAuth/API access per social network - always-on box for the scheduler - database - media storage - ffmpeg and somewhere to run transcodes for anything past text and images ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden.
# Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
# PostFast product brief ## Problem The core loop is the one every scheduler shares and it is genuinely one-shottable: a compose box, a slot queue, a cron tick, one adapter per network. Two things sit outside what a coding agent hands you in a session. The first is paperwork. Only Bluesky and Telegram give you working credentials on signup; the other nine of PostFast's eleven destinations wait behind Meta App Review for Instagram, Facebook, and Threads, a TikTok audit before an app may post publicly rather than to a private draft, YouTube's default 10,000-unit daily quota against 1,600 units per upload, approval flows at LinkedIn, Pinterest, and Google Business Profile, and X, where the free tier is capped tightly enough that real volume means paying. The second is video. Every platform enforces its own container, codec, aspect ratio, duration, and size rules, so anything past text and a JPEG turns into a transcode pipeline with somewhere to actually run the jobs and a retry story for the upload that dies at 90 percent. Build the text-and-image version for the two open networks in a sitting; the rest is review forms and a transcode queue. ## Product outcome Compose posts into a slot-based queue, publish them on schedule to the open-API networks via per-network adapters, and expose the same queue over MCP so a coding agent can schedule too. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - OAuth/API access per social network - always-on box for the scheduler - database - media storage - ffmpeg and somewhere to run transcodes for anything past text and images ## Explicit non-goals for v1 - nine of the eleven destinations, which need app review or a paid API tier rather than more code - pre-approved OAuth apps for Instagram, TikTok, YouTube, LinkedIn, Pinterest, and Google Business Profile - the video pipeline: per-platform container, codec, aspect ratio, duration, and size rules, plus async processing and the retries for when a large upload fails partway - token refresh and the steady patching as platform policies move - analytics, follower history, approval workflows, and per-client workspaces - the hosted API, MCP server, and n8n/Zapier/Make integrations that let an agent post for you ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees.
# Architecture ## Starting brief Build me a personal social scheduler my coding agent can drive, to replace PostFast. Requirements: - Node + Express + better-sqlite3 on my always-on box. Two interfaces over one core: a localhost page (compose box, media attach, queue by send time) and a stdio MCP server via @modelcontextprotocol/sdk with create_post, list_posts, and delete_post, so Claude Code can schedule without me opening the page. - Open-API networks only: Bluesky (app password via @atproto/api), Mastodon (access token), Telegram channel (bot token). One adapter file per network, creds in .env. - For the gated platforms (Instagram, TikTok, YouTube, Facebook, Threads, LinkedIn, Pinterest, Google Business Profile) do not fight the APIs: at send time push me an ntfy.sh alert with the caption and media path and I post by hand. The README says plainly that these need reviewed developer apps, not more code. - Slot-based queue: posting times per weekday in my timezone, new posts take the next free slot or pin to an exact datetime; one post fans out to several networks with per-network text. - A node-cron tick every minute sends what is due, marks the row sending before it calls anything so a crash never double-posts, retries 3 times with backoff, then records sent or failed with the error. - Media in media/ beside the database, images resized per network with sharp. Video: accept MP4 only and check duration, aspect ratio, and size against each network's limits at attach time, rejecting with the limit in the message rather than fixing it. - A history page of the last 100 sends linking to the live posts. - Binds to localhost only. No accounts, no telemetry, everything stays on my box. - Out of scope: video transcoding, analytics, approval workflows, and workspaces. Do not build auth. - README: Bluesky app password, Mastodon token, Telegram bot token, wiring the MCP server into Claude Code, and a warning that social APIs drift and need patching. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it.
# Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone.
# Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations.
# Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted PostFast capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
$ choose a build depth, inspect the files, then open the complete pack in your agent
Connecting Instagram or TikTok here is one click because the OAuth app behind it already passed Meta App Review, TikTok's audit, and Google's business verification, a process that takes weeks and that a solo builder often cannot qualify for at all. Video is the other half of the bill: each platform enforces its own container, codec, aspect ratio, duration, and size rules, so a working scheduler runs a real transcode pipeline with async jobs, retries, and honest failure states rather than one hopeful upload call. The subscription also absorbs the work that never finishes: tokens expiring, per-platform media rules changing, endpoints deprecating on someone else's schedule. Above that sits the part a rebuild would not reach anyway, which is cross-account analytics and follower history, approvals and workspaces for running client accounts, and an API plus MCP server so your agent schedules through it instead of you maintaining a poster forever.
xnine of the eleven destinations, which need app review or a paid API tier rather than more code
xpre-approved OAuth apps for Instagram, TikTok, YouTube, LinkedIn, Pinterest, and Google Business Profile
xthe video pipeline: per-platform container, codec, aspect ratio, duration, and size rules, plus async processing and the retries for when a large upload fails partway
xtoken refresh and the steady patching as platform policies move
xanalytics, follower history, approval workflows, and per-client workspaces
xthe hosted API, MCP server, and n8n/Zapier/Make integrations that let an agent post for you
Don't feel like building it? These folks already made it free.
all 3 free alternatives to PostFast →· no votes, no pay-to-list · just what's real
PostFast pricing
| plan | monthly | annual (per mo) | what you get |
|---|---|---|---|
| starter | $13.84 | $11.53 | 4 social accounts, 150 scheduled posts, 50 drafts, 1 workspace, 1 user, 90-day scheduling window, 30-day history, max 2 X accounts |
| creator | $33.45 | $27.68 | 12 social accounts, 1,500 scheduled posts, 600 drafts, 4 workspaces, 5 users, 180-day window, 1-year history, max 6 X accounts |
| growth | $56.52 | $46.14 | 30 social accounts, 3,000 scheduled posts, 2,000 drafts, 10 workspaces, 8 users, 240-day window, 2-year history, max 12 X accounts |
| pro agency | $114.19 | $95.16 | 120 social accounts, unlimited scheduled posts/drafts, 30 workspaces, 15 users, max 36 X accounts |
| enterprise | $275.66 | $229.53 | 500 social profiles, unlimited scheduled posts/drafts, 110 workspaces, 30 users, max 45 X accounts |
free tierno free tier
billingmonthly + annual (2 months free); 7-day trial, no credit card
hidden costsHard caps apply to social accounts, workspaces, users, queued posts, drafts and X accounts; going past them requires a higher plan. Prices are EUR and USD totals move with exchange rates.
verified 2026-08-14 · source ↗
Vibecode PostFast
Kinda. The core of PostFast is buildable in a weekend with the prompt on this page, but there are real gaps: nine of the eleven destinations, which need app review or a paid API tier rather than more code, pre-approved OAuth apps for Instagram, TikTok, YouTube, LinkedIn, Pinterest, and Google Business Profile. Read the honest list above before committing.
How much does PostFast cost?
PostFast costs about $33.45/month (Creator, checked 2026-08-14), which is $401.40000000000003 per year.
What do I lose by replacing PostFast?
Honestly: nine of the eleven destinations, which need app review or a paid API tier rather than more code; pre-approved OAuth apps for Instagram, TikTok, YouTube, LinkedIn, Pinterest, and Google Business Profile; the video pipeline: per-platform container, codec, aspect ratio, duration, and size rules, plus async processing and the retries for when a large upload fails partway; token refresh and the steady patching as platform policies move; analytics, follower history, approval workflows, and per-client workspaces; the hosted API, MCP server, and n8n/Zapier/Make integrations that let an agent post for you. If any of those are load-bearing for you, keep paying.
Is there an open-source alternative to PostFast?
Yes: Postiz (More networks, team features, analytics, API and MCP; also more databases than a scheduler ought to need.) BrightBean Studio (Publishing, analytics, approvals, API and MCP in a free hosted product; network count is broad, not eleven-shaped.) TryPost (Twelve networks, analytics, approvals, REST and MCP; free software with non-free operational attention.) All 3 curated free alternatives are at vibecodeit.com/postfast/alternatives. The prompt is for when you want it exactly your way.