One control panel. A network of publishing workflows.

A large audience makes repetitive work a systems problem.

I built this for a social media influencer network with a reported combined audience in the tens of millions. The job was to coordinate the publishing work behind that network: getting content from a shared library into the right account workflows.

Behind that reach was a practical coordination problem. Media had to move from a content library into account-specific publishing sessions. Captions, file paths, active machines, and posting modes all needed to agree. Repeating those steps across separate desktops created work that was difficult to direct from one place.

I built a shared control workflow around that problem: prepare assets centrally, tell the right workers what to do, and retain an operator's ability to start or stop the process. My role covered the web interface, cloud connections, Windows automation, and the scripts that moved information between them.

Separate the control panel, the media, and the workers.

The operator interface was a Python Flask application. It exposed routes for uploading content, saving captions, adding worker instances, starting platform workflows, and stopping activity. The historical interface work also separated uploading from posting and introduced a multiple-file upload screen with visible request progress.

Amazon S3 held the media library and small coordination files: captions, the selected media path, a registry of EC2 instance IDs, and a feed of newly discovered Twitter posts. This gave the control panel and remote machines a common place to retrieve content and configuration.

AWS Systems Manager connected the web application to Windows EC2 workers. The dashboard read the instance registry and sent PowerShell commands to update local control files and launch the appropriate scripts. It recorded command IDs and inspected execution status, making remote orchestration part of the application rather than a separate manual desktop task.

On each worker, Python scripts staged the selected assets locally and operated existing browser sessions with Clicknium and PyAutoGUI. That boundary was central to the design: the cloud coordinated storage and commands, while the Windows session performed the platform-facing interaction.

Specific content, library selection, and a clear stop signal.

The TikTok worker supported two distinct modes. Specific mode downloaded the designated S3 video and ran the publishing sequence across configured browsers. Random mode selected media from the shared library for each browser session and repeated the workflow while active. Captions were read from the shared metadata, with separate handling for mentions.

A small file-based protocol connected the controls to the workers. Values represented inactive, specific, and random modes. A local monitor interpreted those values and started the corresponding batch scripts. The January development notes show an explicit request to check the stop flag before starting another random iteration, so further downloads and posting cycles could be halted.

Temporary files were part of the workflow, too. Workers downloaded only the media they needed into a staging directory and removed staged files after use. Later variants added scheduled execution and next-day rescheduling. These details turned a sequence of browser actions into a repeatable operating process.

The stop mechanism was cooperative: a worker checked a flag at an iteration boundary. It did not establish an immediate cancellation guarantee for an upload already underway. Likewise, a successful remote command meant that the command ran; it was not a verified receipt that a social post had appeared.

Keep content discovery separate from publication.

The Twitter side had a separate monitoring pipeline. A Tweepy script read a CSV list of accounts, tracked recently seen posts in memory, and maintained a rolling file of post links in S3. The March 2024 conversation documents work on keeping that feed bounded as new entries arrived.

Publishing workers consumed that feed for reply workflows and also supported original posts. The recovered code selected a small batch of random images from an S3 folder, downloaded them locally, and cleared the staging directory afterward. It also included text-generation calls based on example material and scheduled original/reply jobs.

Tweepy supplied the monitoring connection; browser automation handled the recovered posting workflows. Keeping those responsibilities distinct makes the system easier to explain and its limitations easier to locate. A problem reading a feed is different from a problem preparing media, operating a session, or confirming publication.

The useful abstraction was the whole workflow.

The strongest design decision was combining the pieces into one operator-facing system. A shared media library reduced the need to move assets manually between machines. A worker registry made command fan-out explicit. Separate modes let the operator choose between a particular asset and a reusable content pool. Logs and cleanup made repeated runs easier to inspect.

The implementation also made pragmatic trade-offs. Small files were an approachable coordination mechanism, but they were shared mutable state rather than an immutable job queue. Browser workflows depended on page structure, timing, and an available interactive session. The Twitter monitor's last-seen state lived in memory, so the recovered version did not establish durable deduplication across restarts.

If I rebuilt the system today, I would preserve the separation of control, content, and workers while introducing durable jobs, per-account state, idempotency, and explicit publication receipts. Supported platform APIs, stronger secret management, and a reviewable content queue would be evaluated as part of that redesign. Those are lessons from the project, not features being claimed for the 2024 implementation.

A connected system, with its history still recoverable.

The result was an implemented set of connected components: a web control panel, cloud asset storage, remote command distribution, platform workers, a monitoring feed, and local execution controls. The recovered source and contemporaneous development conversations show how the project progressed from individual posting scripts toward coordinated cloud operations.

The available material supports the system's architecture and implemented workflows. It does not include an operational dataset for publication success rate, posts delivered, uptime, labor saved, or audience impact, so this case study does not assign numbers to those outcomes.

The larger project had separate creation and distribution stages. VidConv was the creation leg: it automated making videos in a viral tweet screen-recording format template. The Amazon S3 system described here was the distribution leg, coordinating stored media and publishing workers. VidConv's public GitHub repository documents the creation tooling; it is not evidence that the S3 distribution backend was published. The full distribution code survives in cloud-drive backups, but this review did not locate its published Git repository.

Explore VidConv, the video-creation leg →