Moloi Method

I run a content operation that publishes 25+ short-form video posts per week across TikTok, Instagram Reels, and Snapchat Spotlight. I do not manually edit clips, write captions, schedule posts, or click publish. The entire pipeline runs autonomously, from the moment a raw video lands in Google Drive to the moment it goes live on three platforms with platform-specific formatting, scheduled at peak engagement hours. This post is the technical walkthrough. I am going to show you the architecture, the code decisions, the scheduling logic, and the results. This is not a concept or a prototype. This system has been running in production since Q3 2025, processing 100+ clips per month with a 99.2% success rate on first-attempt publishing. If you want the business case for automation before the technical details, start with <a href="/blog/ai-automation-roi-small-business">AI Automation ROI for Small Businesses</a>. This post assumes you understand why automation matters and want to see how it works. <h2 id="the-problem-manual-content-takes-15-hours-per-week">The problem: manual content takes 15+ hours per week</h2> Before automation, publishing 25 pieces of content per week looked like this: <table> <thead> <tr> <th>Task</th> <th>Time per post</th> <th>Weekly total (25 posts)</th> </tr> </thead> <tbody> <tr> <td>Clip selection from raw footage</td> <td>8 min</td> <td>3.3 hrs</td> </tr> <tr> <td>Editing and trimming</td> <td>12 min</td> <td>5.0 hrs</td> </tr> <tr> <td>Resizing for each platform</td> <td>5 min</td> <td>2.1 hrs</td> </tr> <tr> <td>Caption writing</td> <td>4 min</td> <td>1.7 hrs</td> </tr> <tr> <td>Scheduling across 3 platforms</td> <td>6 min</td> <td>2.5 hrs</td> </tr> <tr> <td>Quality check and publish</td> <td>3 min</td> <td>1.3 hrs</td> </tr> <tr> <td>Total</td> <td>38 min</td> <td>15.9 hrs</td> </tr> </tbody> </table> Nearly 16 hours per week of repetitive work. Every clip goes through the same process: trim, resize, caption, schedule. The creative decisions (which topics to cover, what footage to shoot) still require human judgment. But everything after the raw footage exists is mechanical. That 16 hours is what I eliminated. <h2 id="architecture-overview">Architecture overview</h2> The pipeline has six stages, each handled by a separate Python script that communicates through the file system and Google Sheets state tracking. <div class="codehilite"><pre><code>Stage 1: Google Drive Watcher (drive_watcher.py) | detects new raw video files Stage 2: Video Clipper (video_clipper.py) | trims clips, applies topic-based naming Stage 3: Platform Resizer (resize_tiktok.py, resize_safezone_batch.py) | generates platform-specific versions Stage 4: Upscaler + Quality Gate (quality_gate.py) | verifies specs, rejects non-conforming clips Stage 5: Scheduler (scheduler.py) | assigns optimal post times Stage 6: OneUp Publisher (oneup_scheduler.py) | publishes to TikTok, Instagram, Snapchat via API </code></pre></div> Each stage reads from and writes to a defined directory structure. There is no message queue, no database, no orchestration framework. Files in a directory are the signal. When a file appears in <code>/stage_2_ready/</code>, the resizer picks it up. When a resized file appears in <code>/stage_3_ready/</code>, the scheduler picks it up. Simple, debuggable, and resilient to crashes. If a stage fails, the files stay in place and get processed on the next run. <h2 id="stage-1-google-drive-watcher">Stage 1: Google Drive watcher</h2> The first agent monitors a specific Google Drive folder for new raw video uploads. When I (or my editor) drops a finished video file into the "Raw Footage" folder, the watcher detects it within 60 seconds. It uses the Google Drive API v3 with a <code>changes.list</code> endpoint that returns file modifications since a stored page token. This is dramatically more efficient than polling the folder listing. Instead of fetching all files and comparing timestamps, the API tells you exactly what changed. The watcher runs every 60 seconds via a cron job. Each cycle it calls <code>changes.list</code> with the stored page token, filters for video files (MP4, MOV) in the target folder, downloads new files to the local processing directory, updates the page token for the next cycle, and logs the event to Google Sheets for tracking. Why Google Drive and not S3 or local storage? Because the editor is not technical. He drops files in a Google Drive folder from his phone or laptop. I am not going to make him learn S3 upload tools or SSH into a server. The input interface has to meet the human where they are. Google Drive is that interface. On error handling: if the Drive API returns a 429 (rate limit), the watcher backs off exponentially starting at 30 seconds. If a download fails mid-transfer, it retries 3 times with checksum validation. Partial downloads get deleted and re-queued. <h2 id="stage-2-video-clipper">Stage 2: video clipper</h2> Raw footage comes in as 10-45 minute videos. The clipper's job is to identify natural segment boundaries, extract individual clips at 30-90 seconds each, and name them by topic. I am not using AI scene detection here. It is overkill for this use case and adds latency. Instead, the clipper uses ffmpeg's silence detection filter to identify natural pauses in speech, which correspond to topic transitions. The command: <div class="codehilite"><pre><code>ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 </code></pre></div> gives me the total duration, and: <div class="codehilite"><pre><code>ffmpeg -i input.mp4 -af silencedetect=noise=-30dB:d=0.8 -f null - </code></pre></div> identifies silence gaps longer than 0.8 seconds at -30dB threshold. Segments between silence gaps become candidate clips. Each clip gets a filename based on its content category, assigned from a predefined topic map in <code>config_loader.py</code>. The categories match our content strategy: market analysis, stock picks, trading education, news commentary. The filename format is <code>{topic}_{date}_{sequence}.mp4</code>. A 30-minute raw video produces 8-12 clips and takes approximately 4 minutes to process on a VPS with 4 cores and 8GB RAM. The bottleneck is ffmpeg transcoding, not the detection logic. <h2 id="stage-3-platform-specific-resizing">Stage 3: platform-specific resizing</h2> This is where the pipeline forks. Each platform has different specs, and getting them wrong means your content gets cropped, compressed badly, or rejected outright. <h3 id="platform-specifications">Platform specifications</h3> <table> <thead> <tr> <th>Platform</th> <th>Resolution</th> <th>Aspect ratio</th> <th>Max duration</th> <th>Safe zones</th> </tr> </thead> <tbody> <tr> <td>TikTok</td> <td>1080 x 1920</td> <td>9:16</td> <td>10 min</td> <td>250px top, 450px bottom, 35px sides</td> </tr> <tr> <td>Instagram Reels</td> <td>1080 x 1920</td> <td>9:16</td> <td>90 sec</td> <td>250px top, 420px bottom, 35px sides</td> </tr> <tr> <td>Snapchat Spotlight</td> <td>608 x 1080</td> <td>9:16</td> <td>60 sec</td> <td>200px top, 380px bottom, 30px sides</td> </tr> </tbody> </table> The safe zones are critical. TikTok overlays the username, caption, and interaction buttons on top of your video. If your key content (text overlays, faces, graphics) falls in those zones, it gets hidden behind UI elements. I spent two weeks measuring the exact pixel boundaries of each platform's UI overlay by analyzing screenshots at multiple device sizes. For TikTok, <code>resize_tiktok.py</code> scales the source to 1080x1920 using Pillow for frame analysis and ffmpeg for the actual resize. It checks that no critical content (detected via contrast analysis) falls within the safe zones. For Snapchat, <code>resize_safezone_batch.py</code> handles the non-standard 608x1080 resolution. Snapchat Spotlight uses a different aspect ratio rendering on their app, and uploading at 1080x1920 causes visible compression artifacts. The dedicated 608-width encode avoids this. Every clip gets text overlays composited via Pillow before final export. This includes the channel watermark, topic label, and any callout graphics. The compositing happens in Python, not ffmpeg, because Pillow gives pixel-level control over text positioning, font rendering, and opacity. ffmpeg's drawtext filter is too limited for the visual quality I need. The ffmpeg encoding command for final output: <div class="codehilite"><pre><code>ffmpeg -i input.mp4 -vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2" -c:v libx264 -preset slow -crf 18 -c:a aac -b:a 192k output.mp4 </code></pre></div> CRF 18 gives near-lossless quality at roughly 8-12 Mbps bitrate. The <code>slow</code> preset increases encoding time by 40% versus <code>medium</code> but produces noticeably better quality at the same file size. Worth it for content that gets compressed again by the platform. <h2 id="stage-4-quality-gate">Stage 4: quality gate</h2> Before anything gets scheduled, every clip passes through an automated quality check. This catches encoding errors, incorrect dimensions, truncated files, and safe zone violations. The checks, in order: <ol> <li>File integrity: ffprobe validates the container, audio streams, and video streams</li> <li>Resolution match: exact pixel dimensions verified against platform target</li> <li>Duration bounds: clips under 15 seconds or over platform max get flagged</li> <li>Bitrate floor: video bitrate must exceed 4 Mbps (below this, quality degrades visibly on mobile)</li> <li>Audio presence: confirms audio track exists and is not silent</li> <li>Safe zone compliance: runs a contrast analysis on the top 250px and bottom 450px to detect content in overlay zones</li> </ol> Clips that fail any check get moved to a <code>/rejected/</code> directory with a log entry describing the failure reason. In production, the rejection rate is 3-4% of clips, and 90% of rejections are duration bounds (clip too short after trimming). <h2 id="stage-5-scheduling-logic">Stage 5: scheduling logic</h2> Posting time matters. A 2025 Sprout Social study found that posting during peak engagement windows increases reach by 23-47% depending on the platform. All posts are scheduled between 12 PM and 9 PM local time in the target audience's timezone. Within that window, the scheduler distributes posts using a weighted random selection that favors historically high-engagement slots. The weight table is updated weekly from Google Sheets where I track per-post engagement metrics: <table> <thead> <tr> <th>Time slot</th> <th>TikTok weight</th> <th>Instagram weight</th> <th>Snapchat weight</th> </tr> </thead> <tbody> <tr> <td>12-1 PM</td> <td>0.8</td> <td>0.7</td> <td>0.6</td> </tr> <tr> <td>1-2 PM</td> <td>0.7</td> <td>0.6</td> <td>0.5</td> </tr> <tr> <td>2-3 PM</td> <td>0.6</td> <td>0.5</td> <td>0.5</td> </tr> <tr> <td>3-4 PM</td> <td>0.7</td> <td>0.6</td> <td>0.6</td> </tr> <tr> <td>4-5 PM</td> <td>0.9</td> <td>0.8</td> <td>0.7</td> </tr> <tr> <td>5-6 PM</td> <td>1.0</td> <td>1.0</td> <td>0.9</td> </tr> <tr> <td>6-7 PM</td> <td>1.0</td> <td>0.9</td> <td>1.0</td> </tr> <tr> <td>7-8 PM</td> <td>0.9</td> <td>0.8</td> <td>0.9</td> </tr> <tr> <td>8-9 PM</td> <td>0.8</td> <td>0.7</td> <td>0.8</td> </tr> </tbody> </table> The scheduler also enforces a minimum 2-hour gap between posts on the same platform. Posting too frequently triggers algorithmic suppression on TikTok. I measured a 34% reach drop when posting more than 3 times in a 4-hour window. When multiple clips are ready simultaneously, the scheduler assigns them across the next 3-5 days, spreading content evenly rather than front-loading. This maintains consistent posting frequency, which the platform algorithms reward. The schedule state lives in a Google Sheet with columns for clip filename, platform, scheduled datetime, post status (scheduled/published/failed), and OneUp job ID. The scheduler writes to this sheet after assigning times, and the publisher reads from it to know what to post when. <h2 id="stage-6-oneup-publisher">Stage 6: OneUp publisher</h2> OneUp is the social media scheduling API that handles the actual publishing. I chose OneUp over Buffer, Hootsuite, or Later because they have a proper REST API (not just a web UI), they support TikTok direct posting (not just reminders), and their pricing does not scale per-post. The publisher (<code>oneup_scheduler.py</code>) runs every 15 minutes. It reads the Google Sheet for clips with status "scheduled" and a publish time within the next 15-minute window, uploads the platform-specific video file to OneUp via their media upload endpoint, creates a scheduled post with the caption, hashtags, and platform-specific settings, and updates the Google Sheet with the OneUp job ID and status "queued." On the next cycle, it checks the status of previously queued posts and updates to "published" or "failed." When a post fails (API timeout, platform rejection, rate limit), the system logs the error with the full API response, retries once with a 30-minute delay, and if the retry fails, flags it for manual review and sends a Discord notification. It also keeps a running tally of failure rates per platform to detect systemic issues. In the last 90 days, the failure rate breakdown: TikTok 1.8%, Instagram 2.4%, Snapchat 0.9%. Instagram is highest because Meta's API has more restrictive rate limits and occasionally rejects videos for undocumented content policy reasons. Every stage logs to the same Google Sheet. This gives me a single view of the entire pipeline: which clips are in processing, which are scheduled, which published successfully, which failed. The sheet also serves as the input for weekly analytics. I can filter by platform, date range, or topic category to see engagement trends. <h2 id="how-agents-hand-off-to-each-other">How agents hand off to each other</h2> The inter-stage communication is file-based, not message-based. This was a deliberate architecture decision. Why not a message queue (RabbitMQ, Redis, SQS)? Because the failure mode matters more than the throughput. If a message queue goes down, you lose the messages and have to replay them. If a file sits in a directory, it stays there until something processes it. The pipeline processes 4-8 clips per day. This is not a high-throughput system that needs sub-second latency. It needs reliability and debuggability. The directory structure: <div class="codehilite"><pre><code>/pipeline/ /01_raw/ # Drive watcher drops files here /02_clipped/ # Clipper outputs individual segments /03_resized/ /tiktok/ # TikTok-spec versions /instagram/ # Instagram-spec versions /snapchat/ # Snapchat-spec versions /04_approved/ # Quality gate passes /05_scheduled/ # Scheduler assigned times /06_published/ # Successfully posted /rejected/ # Failed quality gate /failed/ # Failed publishing </code></pre></div> Each script watches its input directory with a simple polling loop (check every 60 seconds for new files). When it finishes processing a file, it moves the file to the next stage's input directory. The file's presence in a directory IS the state. If the resizer crashes mid-process, the partially processed file stays in <code>/02_clipped/</code>. On restart, the resizer checks for files in its input directory and reprocesses them. There is no state to recover, no database to reconcile. The file system is the state machine. <h2 id="results-90-days-of-production-data">Results: 90 days of production data</h2> Here are the actual numbers from the last 90 days of operation (January through March 2026): <table> <thead> <tr> <th>Metric</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Total clips processed</td> <td>312</td> </tr> <tr> <td>Successfully published</td> <td>297</td> </tr> <tr> <td>Failed (required manual intervention)</td> <td>15</td> </tr> <tr> <td>First-attempt success rate</td> <td>95.2%</td> </tr> <tr> <td>Success rate including retries</td> <td>99.2%</td> </tr> <tr> <td>Average processing time (raw to scheduled)</td> <td>18 minutes</td> </tr> <tr> <td>Posts per week (average)</td> <td>26.4</td> </tr> <tr> <td>Platforms covered</td> <td>3 (TikTok, Instagram, Snapchat)</td> </tr> <tr> <td>Human hours per week on content publishing</td> <td>0.5 (reviewing failed posts only)</td> </tr> </tbody> </table> Before automation: 15.9 hours per week for 25 posts. After automation: 0.5 hours per week for 26+ posts. That is a 97% reduction in manual time. The 0.5 hours that remain go toward reviewing the 1-2 failed posts per week and making creative decisions about upcoming content topics, which is work that actually requires human judgment. <h3 id="engagement-impact">Engagement impact</h3> The automated scheduling actually improved engagement compared to my manual posting schedule: <table> <thead> <tr> <th>Platform</th> <th>Avg views (manual)</th> <th>Avg views (automated)</th> <th>Change</th> </tr> </thead> <tbody> <tr> <td>TikTok</td> <td>2,400</td> <td>3,100</td> <td>+29%</td> </tr> <tr> <td>Instagram</td> <td>1,800</td> <td>2,200</td> <td>+22%</td> </tr> <tr> <td>Snapchat</td> <td>890</td> <td>1,150</td> <td>+29%</td> </tr> </tbody> </table> The improvement comes from two things: consistent posting frequency (algorithms reward daily publishing) and optimized timing (the weighted schedule hits peak engagement windows more reliably than my manual guesswork). <h2 id="what-i-would-do-differently">What I would do differently</h2> I would add AI scene detection for clipping. The silence-based detection works for talking-head content but misses natural topic transitions in footage without speech pauses. A vision model analyzing scene changes would produce better clip boundaries for certain content types. I would build a caption generator. Currently, captions are pulled from a templated set based on topic category. An LLM generating platform-specific captions with trending hashtags would likely improve discovery metrics. I would add A/B testing for post times. The current weight table is updated manually from analytics. An agent that runs controlled experiments, posting the same content at different times and measuring engagement, would optimize the schedule faster than my weekly manual analysis. <h2 id="frequently-asked-questions">Frequently asked questions</h2> <h3 id="how-much-does-it-cost-to-run-this-pipeline">How much does it cost to run this pipeline?</h3> The infrastructure cost is approximately $45/month: $20 for the VPS (4 core, 8GB RAM), $15 for OneUp API access, and $10 for Google Cloud API usage (Drive and Sheets). The development cost was roughly 120 hours of engineering time over 6 weeks. If you hired someone to build this, budget $8,000-$12,000 for the initial build and $200-$400/month for maintenance. <h3 id="can-this-pipeline-work-for-platforms-other-than-tiktok-instagram-and-snapchat">Can this pipeline work for platforms other than TikTok, Instagram, and Snapchat?</h3> Yes. The architecture is platform-agnostic. Each platform is a separate resizer module and a separate OneUp publishing configuration. Adding YouTube Shorts, Facebook Reels, or LinkedIn Video requires writing a new resizer module (2-3 hours of work) and adding the platform to the OneUp scheduler (1 hour). The core pipeline logic does not change. <h3 id="what-happens-when-a-platform-changes-its-api-or-video-specs">What happens when a platform changes its API or video specs?</h3> This is exactly why I build with a maintenance-first architecture. Each platform's specs are defined in a config file, not hardcoded. When TikTok changes their safe zone dimensions (they did twice in 2025), I update one config value and the entire pipeline adapts. API changes require more work. When OneUp updated their v3 API in January 2026, the migration took 4 hours. This is the maintenance work that makes the ongoing $200-$400/month worthwhile. <h3 id="do-i-need-to-be-technical-to-use-a-system-like-this">Do I need to be technical to use a system like this?</h3> To build it, yes. To operate it, no. Once deployed, the system runs autonomously. The operator's interface is Google Drive (drop files in a folder) and Google Sheets (monitor the pipeline status). When something fails, a Discord notification tells you what broke and whether it auto-recovered. My partner Jake, who does not write code, manages the entire content operation through those two interfaces. <hr /> This pipeline is the kind of system I build for clients through the <a href="/">Moloi Method</a>. If you are spending 10+ hours per week on repetitive content operations, there is almost certainly a version of this architecture that fits your workflow. The first step is an <a href="/services/automation-audit">automation audit</a> where I map your current process and identify exactly which stages can be automated. For the business case behind automation investments like this, read <a href="/blog/ai-automation-roi-small-business">AI Automation ROI for Small Businesses</a>. And if you want to understand how AI agents differ from simpler tools like Zapier that cannot handle this kind of multi-stage pipeline, see <a href="/blog/ai-agents-vs-zapier">AI Agents vs Zapier</a>.

How I Built a Fully Automated Content Pipeline: 25+ Posts/Week With Zero Manual Work