Can Aidelly be vibe coded?
AI agent that runs client social media accounts: publish, approvals, DMs, reports, driven from Claude/ChatGPT via MCP or its own app
The agent layer is the buildable part: a focused implementation of vibe coding gets you an MCP server that posts to Bluesky and Mastodon, whose APIs are open. Everything after that is the product: approved OAuth apps for Meta, TikTok, YouTube, LinkedIn, X and Google Business (app review processes measured in weeks, and X's API is pay-per-use), token refresh across eleven platforms that silently break in eleven different ways, publish retry/recovery infrastructure, per-client workspaces with approval workflows, and white-label so agency clients never see the tool. The integration upkeep is not a one-shot; it is the 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
- An MCP server exposing post-now and schedule tools that publish text and images to Bluesky and Mastodon from a cron-backed queue.
- 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
- the closed platforms: Meta, TikTok, YouTube, X and Google Business need approved developer apps and policy compliance
- client approval workflows and per-client workspace isolation
- white-label (your clients seeing your brand, not your stack)
- publish reliability infrastructure: retries, token-refresh, failure emails, watchdogs
- Connectors, OAuth flows, and vendor API changes require constant upkeep.
- Years of history, configuration, and habits make migration costly.
Build, switch, or keep paying
Narrower, with trade-offs
An MCP server exposing post-now and schedule tools that publish text and images to Bluesky and Mastodon from a cron-backed queue.
Use the build brief ↓2 checked options
Recommended
Agencies pay because the eleven-platform integration surface is a permanent maintenance treadmill they'd rather not own, and because the workflow around posting (client approvals, white-label reports, per-client isolation) is what they actually sell to their own customers. The AI-agent angle, driving all of it from Claude via MCP, is the part a DIY build can copy; the platform access underneath is the part it can't.
Visit Aidelly ↗Why people still pay
Agencies pay because the eleven-platform integration surface is a permanent maintenance treadmill they'd rather not own, and because the workflow around posting (client approvals, white-label reports, per-client isolation) is what they actually sell to their own customers. The AI-agent angle, driving all of it from Claude via MCP, is the part a DIY build can copy; the platform access underneath is the part it can't.
Connectors, OAuth flows, and vendor API changes require constant upkeep.
Years of history, configuration, and habits make migration costly.
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 Aidelly
Context
Aidelly — AI agent that runs client social media accounts: publish, approvals, DMs, reports, driven from Claude/ChatGPT via MCP or its own app. It currently costs $29/mo.
The agent layer is the buildable part: a focused implementation of vibe coding gets you an MCP server that posts to Bluesky and Mastodon, whose APIs are open. Everything after that is the product: approved OAuth apps for Meta, TikTok, YouTube, LinkedIn, X and Google Business (app review processes measured in weeks, and X's API is pay-per-use), token refresh across eleven platforms that silently break in eleven different ways, publish retry/recovery infrastructure, per-client workspaces with approval workflows, and white-label so agency clients never see the tool. The integration upkeep is not a one-shot; it is the job.
This brief describes a focused, single-operator replacement for the part of Aidelly 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
An MCP server exposing post-now and schedule tools that publish text and images to Bluesky and Mastodon from a cron-backed queue.
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
Bluesky app password + Mastodon app registration.
Hosted scheduler/cron.
Database for queue and post state.
Media storage.
Developer app approval from each closed platform (Meta, TikTok, YouTube, X) for anything beyond the open ones.
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 social publishing agent: an MCP server (TypeScript, official SDK) exposing tools post_now, schedule_post, list_queue and cancel_post. Posts go to Bluesky (atproto, app-password auth, image + video upload via the video service) and Mastodon (masto.js, app registration). schedule_post writes to a SQLite queue; a cron worker publishes due posts with retry and exponential backoff, and failed posts surface through a get_failures tool instead of silently dropping. Include a dry-run mode that previews the per-platform rendering (300-grapheme limit handling for Bluesky, 500 chars for Mastodon) before anything goes live.
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:
The closed platforms: Meta, TikTok, YouTube, X and Google Business need approved developer apps and policy compliance.
Client approval workflows and per-client workspace isolation.
White-label (your clients seeing your brand, not your stack).
Publish reliability infrastructure: retries, token-refresh, failure emails, watchdogs.
Inbox/DM automation and cross-client analytics reports.
What you still own after launch
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 — Self-hosted scheduler for 20+ platforms; you still bring your own developer apps for the closed ones
Mixpost — Laravel self-hosted social scheduling; lite tier is free, same bring-your-own-OAuth catch
Prior art
Working open-source software you can read, fork, or borrow from before starting:
atproto (official SDK) — Bluesky's TypeScript SDK: posting, video uploads, the whole protocol
masto.js — Full-featured Mastodon API client for the other open platform
MCP TypeScript SDK — Build the agent-facing tool server the DIY version is really about
Generated by Can It Be Vibe Coded? · Full report: https://www.canitbevibecoded.com/aidelly
You still own the product
- 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 Aidelly yet. A submission is evidence for review, not automatic proof that the whole product was replaced.
Built a version of Aidelly?Submit the project as evidence for this report.
Open-source prior art
Before you start
Can Aidelly be vibe coded?
Not faithfully. The agent layer is the buildable part: a focused implementation of vibe coding gets you an MCP server that posts to Bluesky and Mastodon, whose APIs are open. Everything after that is the product: approved OAuth apps for Meta, TikTok, YouTube, LinkedIn, X and Google Business (app review processes measured in weeks, and X's API is pay-per-use), token refresh across eleven platforms that silently break in eleven different ways, publish retry/recovery infrastructure, per-client workspaces with approval workflows, and white-label so agency clients never see the tool. The integration upkeep is not a one-shot; it is the job.
What can an AI coding agent reproduce from Aidelly?
An MCP server exposing post-now and schedule tools that publish text and images to Bluesky and Mastodon from a cron-backed queue. 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 Aidelly replacement still be missing?
the closed platforms: Meta, TikTok, YouTube, X and Google Business need approved developer apps and policy compliance; client approval workflows and per-client workspace isolation; white-label (your clients seeing your brand, not your stack); publish reliability infrastructure: retries, token-refresh, failure emails, watchdogs; Connectors, OAuth flows, and vendor API changes require constant upkeep.; Years of history, configuration, and habits make migration costly.
What do I still own after building a Aidelly alternative?
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.