UGC Trackr — the platform an agency runs on, and sells

An agency runs on data it doesn't own

A UGC agency's work lives on other people's platforms. Creators post to social networks; the performance data that proves a campaign worked sits behind those networks' APIs and rate limits. Meanwhile the agency has to know who is on which campaign, whether the work was delivered, and what everyone is owed.

So the product has two halves that pull in different directions: a continuous ingestion problem, where data arrives from systems you don't control and can't rush, and a money problem, where numbers have to be exactly right because people get paid from them.

The interesting constraint isn't either half on its own. It's that payouts are computed from data scraped out of platforms that can rate-limit you.

Ingestion: pulling performance data in

Social ingestion runs on Apify actors, layered with queues, webhooks and scheduled refreshes. Posts get pulled in, enriched, analysed and aggregated on a cycle rather than on demand.

That scheduling is the design decision. Enrichment can't be synchronous — you cannot make a dashboard request wait on a third-party scrape — so the work is pushed onto eight scheduled jobs covering aggregation, media analysis, attribution, Instagram refreshes, workspace syncing, alerts and payroll generation. The UI reads what the crons have already settled.

Media handling sits alongside it: download endpoints for video, slideshows and thumbnails, so the agency keeps the assets rather than depending on a post staying up.

Payroll and payouts: where correctness stops being negotiable

The payout path runs from campaign performance through invoice review and funding to reconciliation, with Stripe Connect onboarding so creators can actually receive money. Creators see their own payout status through a dedicated portal.

This is the part of the system where bugs are expensive in a way dashboards never are. A wrong number on a leaderboard is embarrassing; a wrong number on an invoice is somebody's income. It's also why payout generation is a scheduled, reviewable step with a human in the loop rather than something that fires automatically off a scraped metric.

One codebase, two businesses

The part I find most interesting architecturally is that Playkit uses Trackr internally and sells it. Those are different products wearing the same code.

The mechanism is sponsored client workspaces: campaigns Playkit owns, surfaced to client teams who can see and edit their slice without seeing anyone else's. That means tenancy isn't a boundary bolted around the edge of the app — it runs through the data model and the role-gated routing, and every new feature has to answer "who can see this" before it ships.

Supporting both audiences also drives things like a demo mode and tiering, so the product can be shown and sold without exposing live agency data.

Shape of the system

• 82 serverless endpoints under api/ — covering ingestion, analytics, payroll, notifications, uploads and integration webhooks, plus 26 shared helper modules
• 16 of those endpoints are Stripe alone, which is a fair measure of how much surface area moving money actually takes
• 8 scheduled jobs driving everything that can't happen in a request cycle
• Role-gated routing with an invite and team-admin flow
• Public share routes — campaign, gallery, creator profile and portfolio views that work without an account
• A documented read-only external API for integration partners

Vue 3 · Vite · Pinia · Supabase · Tailwind · Vercel functions · Apify · Stripe Connect · Instagram API · PostHog