Social publishing platform

What it is, and what it proves

Socialog is a social-media scheduler. Write a post once, attach media, pick the connected accounts and a time, and it publishes to X, Instagram, Threads, LinkedIn, YouTube, Pinterest and Paragraph, each through that platform's own API. "Publish one post to seven networks, reliably, on a schedule" sounds simple and is not: every network has a different API, and a scheduler that double-posts or silently drops a post is worse than none.

One person built Socialog and runs it: the product, the publish engine, billing, the marketing site, and the mascot (Memo, a small elephant who "never forgets to post"). For a buyer, it is evidence of three things: a production SaaS with real third-party integrations shipped by a very small team, reliability engineered in from the start, and an AI-agent interface you could have in your own product.

A complete product, not a demo

The core is a calendar and a composer. Draft a post, attach images or video from a media library, pick the target accounts, and either save a draft or schedule it. Each account is a separate publish target underneath, so one network failing does not take the others down.

Around that sits everything a paying customer expects: OAuth connections per network, teams sharing one content calendar, per-plan limits enforced through billing, and analytics pulled back from the platforms that expose them. A content studio assembles short-form vertical video from images, clips and music, with AI generation on top, and feeds straight back into the scheduler.

Every post goes out exactly once

The publish engine is a small queue built to be correct. Every minute a scheduled tick claims the posts that are due and publishes them. Ticks can overlap and workers can die mid-publish, so claiming is atomic: two ticks can never pick up the same post, and each takes a bounded batch so a backlog drains steadily.

Failures are classified, not just retried. Retryable ones go back in the queue with backoff and a cap; fatal ones fail fast with a status the user can see. Some platforms publish in several steps that can be interrupted halfway, so the engine records its progress and a retry resumes the publish it started instead of creating a duplicate post. The engine is independent of the runtime, so the same code runs under a local ticker in development.

New networks without new risk

Each network lives behind its own adapter with one shared contract. The engine hands over a neutral description of "this post, this media, this account" and the adapter handles that platform's quirks: X's media upload, Meta's multi-step create-then-publish, Paragraph's newsletter emails. Queueing, retries and exactly-once logic live once, in the engine, so a new network inherits all of it. A fake publisher stands in for demo accounts, so the whole product can be shown and tested end to end without posting to a real profile.

Media is stored in R2 and served from a public URL because the platforms fetch it themselves at publish time. Treating media as "already a public URL" by the time it reaches an adapter keeps every adapter simpler.

Built for AI agents

Socialog can be driven by a person in a calendar or by an AI agent over a tool call, and both go through the same core. Next to a versioned REST API there is a full MCP server: list and create posts, attach media, read analytics, list connected accounts. Tools are scoped (posts:read, posts:write, and so on) and authenticated with API keys, using the same scopes that gate the REST API.

Because the agent interface is built on the same server functions as the UI, there is one definition of what "create a post" means. An agent can prepare a scheduled post and leave the accounts for a person to attach later; a post that reaches its time with no accounts is skipped rather than published to nowhere. We build the same pattern into products that need to be usable by agents.

Small enough for one person to run

The whole product (app, API, publish engine, webhooks) ships as a single Cloudflare Worker on TanStack Start and React 19. Postgres is reached through Hyperdrive for pooled connections from the edge, with Drizzle as the data layer. One deploy, one runtime, one place for secrets: that is what keeps it maintainable by one person.

Auth is Better Auth with passkeys; billing is Polar, with plan limits enforced inside the publish loop itself, so they hold at the moment of publishing and not only in the UI. Users' platform OAuth tokens are encrypted at rest and decrypted only when a publish call needs them. A second scheduled job syncs engagement analytics back, reusing the same adapter-per-network shape.

What a buyer should take from it

A user sees "I scheduled a post and it went out." Underneath are race-free claiming, a separate adapter for each network's API, encrypted tokens, idempotent retries against services that can duplicate on you, and a queue on infrastructure that may stop a process mid-request. One person built it and keeps it running.