Case study
Building the system I needed to stop losing content to three open tabs.
Not a scheduler with extra steps — a distribution and growth system built around how a podcast episode actually turns into a dozen pieces of platform-specific content.
The problem
The episode was never the bottleneck. Distributing it was.
Hamrah Podcast doesn't produce one file per episode — it produces a full episode, a trailer, several reels cut from the conversation, and a couple of quote posts, each one meant for a different platform with its own caption, its own hashtags, and its own posting time. Running that by hand across YouTube, Instagram and Facebook meant opening each one separately, retyping captions, and losing track of which clip had actually gone out where. Some finished reels sat unused for weeks simply because nobody remembered they existed.
The real gap wasn't publishing — it was knowing, at a glance, what existed, where it had been distributed, and what was still missing.
The approach
Model the workflow first: Create → Organize → Variant → Distribute → Track → Learn → Reuse.
Before writing a single controller, the workflow got modeled as data: a Workspace owns SocialAccounts and Campaigns; a campaign groups ContentAssets (the full episode, the trailer, each reel); an asset can have multiple ContentVariants (Hook A vs. Hook B); and each variant gets a PlatformVersion — its own title, caption and hashtags per destination. A Distribution then connects a variant to a social account as a scheduled or published post. That chain is what lets the system answer "where has this actually gone out" without guessing.
Every platform got its own capability definition instead of one shared composer form — what content types it accepts, whether it supports native scheduling, its caption length limit, its thumbnail rules. The composer UI reads that capability object at runtime, so adding a platform later means writing an adapter, not rewriting the publishing screen.
The growth side follows the same no-magic principle: an ActionEngine runs rule-based checks — a ready asset with no destination, a campaign only 66% distributed, a token expiring, a winner that's never been reposted — and a DistributionScoreService turns campaign completeness into a transparent, inspectable score instead of an opaque algorithm. None of it depends on a paid AI service; the spec was explicit that V1 had to be useful with AI turned off entirely.
The architecture
What's actually running under it.
- Backend
Laravel 11withLivewirefor the dashboard, calendar, campaigns, content library, publish composer and queue screens — no separate SPA build.- Platform adapters
- Dedicated
YouTube,InstagramandFacebookpublisher classes behind a sharedPlatformPublishercontract and aPlatformCapabilitieslayer, withGoogleOAuthProviderandMetaOAuthProviderhandling authorization per provider. - Publishing
- A queued
PublishDistributionJobcarries each post through preflight validation, media prep, upload and platform-processing stages instead of blocking the request thread. - Domain model
Workspace → SocialAccount / Campaign → ContentAsset → ContentVariant → PlatformVersion → Distribution → PublishedPost, withAnalyticsSnapshotrows kept as a time series rather than overwritten totals.- Growth logic
ActionEngine,DistributionScoreService,CampaignAnalyticsServiceandRepurposeTrackerService— all rule-based, all inspectable, none dependent on an AI subscription.- Reliability
AccountHealthChecker,PublishingErrorClassifierandActivityLoggerturn raw provider failures into a readable reason and a suggested fix instead of a bare error code.
The outcome
Built for one workspace first, structured for more later.
Content OS now runs Hamrah Podcast's own distribution — campaigns, variants, the distribution matrix, and the composer's platform-specific tabs are live and in daily use, with Viral Himachal as a second workspace already proving the multi-workspace model wasn't just a nice-to-have on paper. Deeper analytics sync tuning, the repurpose tracker's full UI, and TikTok as a fourth adapter are the explicit next steps, not hidden gaps.
It was never built to be sold — it was built because Hamrah Podcast needed a real command center, not another spreadsheet. If it keeps proving itself against real episodes, packaging it for other creators running the same three-platform grind is the obvious next question.
Publishing the same content across multiple platforms and tired of doing it by hand?
Get in touch