AI Social Media manager. Months of posts planned ahead
01. Starting point
Running several social profiles means dozens of small tasks spread over time. A post has to be written, matched with a graphic, then published at the right moment, which is usually when something else is already happening.
Publishing was manual. Content was prepared earlier, but sending it still required presence: someone had to open the app, paste the text, attach the graphic, and hit publish. A post scheduled for Saturday morning meant work on Saturday morning. Materials waiting to go out lived in notes, on a drive, and in messages to yourself.
The consequences were predictable. Publishing regularity depended on current workload, not on an agreed plan. A seasonal campaign prepared in advance still required opening the app on the holiday itself. Checking what went out and when meant scrolling the profile, because there was no real history anywhere.
02. Solution
We built an application where the full publishing schedule is prepared in advance, and the system publishes on its own.
Instagram, Facebook, and LinkedIn accounts are connected once. A post is created in one place: text, graphic, links, everything a given platform requires. Then it lands in the calendar on a specific day and time.
At the set time the post goes out without a person in the loop. You can plan several months ahead this way, or prepare seasonal posts early and come back only after the fact to check results.
03. How it works
Calendar as the main view
The starting point is not a post list, but a calendar with the publishing layout across days and hours. You see immediately where the plan is dense, where it is empty, and which channel a given post belongs to.
A post can be moved to another slot, duplicated, or prepared in several variants for different platforms. The same message needs a different framing on LinkedIn than on Instagram, so the system does not force one shared format.
Publishing without a person in the loop
Scheduled posts go through a queue and publish automatically at the set time through the official platform APIs. A failed publish does not disappear quietly: it is flagged and can be retried after the cause is fixed, for example after refreshing expired account access.
History and statistics
The application stores a full publishing history across all connected channels, with status and go-live time. It also pulls engagement data: likes, reactions, reach, and interactions.
A single view answers what scrolling profiles cannot: which content, on which platform, and at which time actually works. That knowledge feeds the next publishing plan.
An assistant that writes in the brand voice
A post can be written by hand and handed to the assistant for editing, or the assistant can draft it from scratch. The difference from a generic language model is what the assistant works on.
The system is loaded with communication rules for a specific brand: tone, vocabulary, forms the brand uses and avoids, how it addresses the audience, and the typical post layout per platform. The assistant does not write correctly in general; it writes correctly for that client.
The effect shows best in editing. A rough draft comes back shorter, structured, and translated into the language the brand uses every day, without being smoothed into the neutral mush that marks machine-generated copy. The rule set is prepared separately for each managed profile and can grow as brand communication changes.
Watching platform connections
Social account access expires. That is the most common cause of silent failures in tools of this class: the schedule looks fine, but posts stop going out because the platform invalidated a token and nobody noticed.
The system periodically verifies every connected account and, if a connection is lost, sends an email notification. The problem surfaces before a scheduled post is missed, not a week later when checking stats.
Technologies used
- Frontend: React 19, TypeScript, Vite, Tailwind CSS, calendar view with drag-and-drop
- Backend: Node.js 22, Fastify 5, TypeScript
- Database: PostgreSQL 16, Prisma ORM
- Publishing queue: recurring jobs with retries for failed attempts
- Image files: object storage, conversion to formats required by platforms
- AI layer: Anthropic SDK, communication rule sets defined per brand
- Integrations: Meta Graph API for Facebook and Instagram, LinkedIn API
- Authentication: OAuth when connecting accounts, tokens refreshed automatically
- Integration monitoring: periodic connection checks, email alerts via Nodemailer
- Validation: Zod, shared between frontend and API
- Deployment: Docker, nginx, Let’s Encrypt certificate
04. Results
Publishing stopped requiring presence. Work concentrates in one planning session and spreads across weeks of outgoing content. Saturday morning and the first day of a holiday are handled by the system.
Regularity stopped depending on workload. A plan set once runs regardless of what happens that week, and gaps in the schedule are visible ahead of time, not after the fact.
Content stopped living in several places at once. Graphics, copy, and dates that used to sit in notes and on a drive now have one place where they are also published.
Language consistency stopped depending on who happens to write the post. Brand communication rules live in the system, not in one person’s head, so a rushed draft sounds like one written with time to spare.
History and stats give a basis for the next publishing decisions. You know what worked, instead of vaguely remembering that something seemed to go better.
