Trusted Tech Leader/ Case studies

Case study · Developer & content tools

Multi-platform short-video publisher with dashboard

A local command-line tool and dashboard that publishes one vertical video to four social platforms, retrying only the platforms that failed.

Sector
Creator tooling and social media
Category
Developer & content tools
Maturity
Working local tool with unit tests per platform adapter

At a glance

Who it's for
Solo creators who post the same short video to several networks.
Core stack
Python, OAuth 2.0 with PKCE, PostgreSQL or JSON files, pytest
What sets it apart
A local publisher that handles each network's upload quirks behind one command and one dashboard.
On this page

What it looks like in use

A dashboard that lists every video post, shows its status on each network, and tells you which one needs another try.

Publisher: All posts
PostsSync analytics
AllQueuedScheduledPublishedPartialFailed
Desk tidy video

Three tips for a tidy desk

Queued
Coffee video

A better morning coffee

Scheduled
Plant video

Repotting a houseplant

Partial
Walk video

A ten minute lunch walk

Published
Repotting a houseplant (Partial)
YouTubePublished
InstagramPublished
LinkedInPublished
TikTokFailed
What is in a post folder
One video fileVideo
A short note with the title, caption and platformspost.json
Posts are created by dropping a folder in the inbox and running the post command.
Run the post command again, only TikTok is retried
Illustrative screen sample data, not client data

Real screens from the working product (sample data)

List of queued and scheduled sample video posts, each shown per network with its status.
Real screen, sample data The Scheduled tab, which also lists queued posts, shown per network with placeholder thumbnails.

From one video to four networks

  1. You drop a video in a folder

    Each post is a folder with your video and a short note holding the title and caption.

  2. The tool checks the post

    It makes sure the video and note are in order before anything is sent.

  3. It posts to each network

    One command sends your video to YouTube, Instagram, LinkedIn and TikTok in turn.

  4. You see what worked

    The dashboard shows each network as published or failed, so nothing is a guess.

  5. You run it again to fix a failure

    Only the network that failed is tried again, and a finished post moves to the done folder.

The challenge

Publishing one short vertical video to several networks means logging into each platform, re-uploading, rewriting captions to fit each limit and tracking which uploads succeeded.

Each platform has its own authorization flow, upload protocol and quirks. One accepts only a public video URL, another lands uploads only in drafts, tokens expire on different schedules, and a personal profile on one network cannot be posted to through its API at all. A naive script fails on these constraints.

The solution

A Python command-line tool reads one folder per post (a video plus a metadata file), validates it, and publishes through a common adapter interface for each platform.

Results are stored per platform, so a re-run retries only the failures, and fully successful posts move to a done folder. A localhost dashboard shows queued, scheduled and published posts with per-platform state and analytics. A temporary tunnel exposes a single file when a platform needs a public link.

For your technical teamhow it works under the hood

One post, four platforms, results kept per platform

Swimlane of publishing one post folder to several platformsSwimlane with five lanes: post folder, command-line tool, platform adapter, tunnel helper and result store. Step 1: a post folder holds a video and a metadata file. Step 2: the command-line tool validates it and skips platforms that already succeeded. Step 3: an adapter publishes to each remaining platform in turn. Step 3a: if a platform needs a public video URL, the adapter asks the tunnel helper for a temporary link. Step 4: the result for each platform, ok or error, is recorded in the result store. Step 5: if every platform succeeded the folder moves to the done folder; otherwise it stays in the inbox and a rerun tries only the failed platforms.POST FOLDERCLIPLATFORM ADAPTERTUNNEL HELPERRESULT STORE1 Post foldervideo and post.json2 Validatevideo and metadataskip platforms done3 Publishone adapter perplatform, in turn3a Public linkonly if a platformneeds a video URL4 Record resultok or error, perplatform5 Finished?all ok: move tothe done foldernot all ok: folder stays in the inbox; a rerun tries only the failed ones
Each platform gets its own result, so one failure does not undo the others. Only a fully successful post leaves the inbox, and a rerun skips platforms that already worked.

Key features

What the system does, as built in the codebase.

  • 01

    Folder-based post inbox

    Each post is a video plus metadata, with per-platform caption overrides and platform selection.

  • 02

    Four platform adapters

    Video, short-form and draft-inbox uploads behind one interface.

  • 03

    Dry-run mode

    Validates tokens and inputs without uploading anything.

  • 04

    Retry only failures

    Per-platform results are saved, so reruns skip successes.

  • 05

    One-time browser login

    OAuth with PKCE and a one-shot localhost callback, then token refresh.

  • 06

    Temporary public file link

    Serves one file under an unguessable path through a tunnel and tears it down after upload.

  • 07

    Local dashboard

    Queue, scheduled, published and analytics views, available on localhost only.

  • 08

    Chunked resumable uploads

    Upload planning for large videos.

How it fits together

From a folder with a video to four platforms, with results tracked per platform.

  1. Post inbox foldervideo and metadata
  2. CLI and validationdry-run, platform selection
  3. Platform adaptersfour networks, one interface
  4. Tunnel helpertemporary public file link
  5. Result storePostgres or JSON files
  6. Local dashboardqueue, status, analytics
A post folder is validated by the command-line tool and published through one adapter per platform. A tunnel helper exposes a file when a platform needs a public link. Per-platform results go to a store that the local dashboard reads.
  • Adapters write per-platform results to the store.
  • The dashboard reads the store and synced analytics.

Implementation notes

Engineering decisions worth knowing about.

  1. One interface per platform

    An abstract platform interface with login, check, publish and dry-run semantics keeps each network isolated.

  2. Flexible storage

    Postgres is used when a database URL is set, and JSON files otherwise, with a migration command.

  3. Tunnel fallback

    The tunnel helper falls back from a quick-tunnel service to an SSH reverse tunnel.

  4. Local credentials

    Tokens, environment files and posts are git-ignored and stored owner-only.

  5. Broad test coverage

    Tests cover each adapter, analytics per platform, the store, accounts, the tunnel and the UI.

  6. Compliance choice

    A platform whose terms forbid automation is handled through an approval-gated browser step rather than an API.

  7. Command set

    Subcommands cover login, status, post, inbox runs, sync, import of scheduled content and the UI.

Technology stack

Taken from the project's dependency and config files.

Language
  • Python
HTTP
  • requests
  • urllib3
  • Standard-library HTTP servers
Data
  • PostgreSQL via psycopg
  • JSON file fallback
Auth
  • OAuth 2.0 with PKCE
Networking
  • Cloudflare quick tunnel
  • SSH reverse tunnel
Testing
  • pytest
For your technical teamtechnology layers

Technology layers

Technology stack layers of the short-video publisherLayered diagram, top to bottom: language (Python); HTTP (requests, urllib3, standard-library HTTP servers); auth (OAuth 2.0 with PKCE); networking (Cloudflare quick tunnel, SSH reverse tunnel); data (PostgreSQL via psycopg, JSON file fallback); testing (pytest).LANGUAGEPythonHTTPrequestsurllib3Standard-library HTTP serversAUTHOAuth 2.0 with PKCENETWORKINGCloudflare quick tunnelSSH reverse tunnelDATAPostgreSQL via psycopgJSON file fallbackTESTINGpytest
A small Python program talks to each network over HTTP with OAuth. Tunnels are used only when a platform needs a public link, and storage is Postgres or plain JSON files.

Business value

What the system enables. No numbers are claimed.

  • Removes re-uploading and most per-network caption work.
  • Makes partial failures safe to retry without duplicate posts.
  • Keeps credentials local and under the creator's control.
  • Gives one view of what is queued, scheduled and live.

Need a system like this built?

Tell us what it needs to do and we will scope it with you on a call.

Discuss a build