Social media autopilot for a network of communities

The client managed over 30 communities on a major social platform as part of their SEO link-building strategy. Each community needed regular posts — two to three per day, with images, on a schedule that matched peak engagement hours. A single person was doing all of it: finding content, resizing images, writing captions, posting manually, then logging into each account the next day to check if anything got flagged. It was a full-time job that produced maybe 60 posts a day with no room to scale.

posting pipeline

We built a full posting pipeline inside their platform. It starts with content sourcing — Python scrapers run on a schedule, collecting posts from public sources based on configurable filters: topic, engagement threshold, media type. The scraped content lands in a database queue where it's deduplicated, tagged, and paired with downloaded images. From there, the scheduling engine takes over. Each community has its own posting calendar with time slots, and the system distributes queued content across slots automatically, balancing freshness and variety. The team can override anything — swap an image, rewrite a caption, move a post to a different time — but the default mode is hands-off.

account rotation

The real complexity lives in account management. The social platform aggressively detects automation, and getting an account restricted means losing access to every community it manages. We built an account rotation layer that spreads posting activity across multiple accounts, respects per-account rate limits, and randomizes timing within each slot to avoid machine-like patterns. Sessions are stored in the database and reused across restarts — no re-authentication unless the session actually expires. A ban checker runs periodically, testing each account's ability to perform basic actions. If an account gets restricted, the system immediately redistributes its communities to healthy accounts and sends a notification.

python scrapers

The Python scrapers presented an architectural challenge. They run as separate processes alongside the Node.js application, which means coordination happens through the database rather than direct function calls. A scraper writes collected content to a staging table with a status field; the Node.js scheduler picks up rows marked as ready. This works, but it means monitoring has to cover two runtimes. We added health checks for both sides — the scrapers report their last successful run and item count to a shared status table, and the main app alerts if either metric goes stale.

image preprocessing

Image management turned out to need more attention than we initially planned. The platform has specific requirements for image dimensions, file size, and format. Uploaded images that don't meet the spec get silently downscaled or cropped in unpredictable ways. We added a preprocessing step that normalizes every image before it enters the queue — resize to optimal dimensions, compress to target file size, convert to the accepted format. This eliminated a class of issues where posts would go live with mangled thumbnails.

results

The system now pushes out 200+ posts per day across all communities with one person spending about 30 minutes on oversight. Account survival improved significantly once we tuned the rotation and timing randomization — from losing two to three accounts per week to roughly one per month. The takeaway that stuck with us: when you're automating against a platform that actively fights automation, the bot logic is the easy part. The hard part is making the automation look human enough to survive, and building the detection and recovery systems for when it doesn't.

Backend: Next.js 14 (Route Handlers), Prisma, PostgreSQL

Social API: VK API (posting, group management, stats)

Scrapers: Python (content collection, separate processes)

Scheduling: node-cron for posting calendar and health checks