CreatorOS

Content operations for cross-platform creator teams.

Comment

Inspiration

Small creator teams increasingly publish like media companies, but their operations are usually fragmented. Strategy lives in one document, the monthly calendar in another tool, platform drafts in separate editors, and performance data in a spreadsheet. AI can generate another caption, but it does not keep the work connected from planning through execution and learning.

That gap inspired CreatorOS. I wanted to build an English-first B2B workspace for independent creators, small studios, and cross-border teams that publish across LinkedIn, X, YouTube, and Rednote. The goal was not to create another chat-first writing tool. It was to prove that one product could carry the same strategy through a complete content operations loop.

What it does

CreatorOS helps a team plan the next 30 posts, adapt each idea for different platforms, track execution, collect performance data, and turn the results into the next actions.

The workflow starts with Account DNA: the creator's niche, audience, platforms, cadence, tone, and goals. That context becomes a monthly plan. Each planned idea opens as a production unit containing its outline, draft, platform variants, workflow status, and metrics.

Teams can:

  1. Create a reusable Account DNA and 30-day content plan.
  2. Adapt one source idea for LinkedIn, X, YouTube, and Rednote.
  3. Compare platform previews, hook alternatives, and tone options.
  4. Move posts through Idea -> Drafting -> Review -> Scheduled -> Published.
  5. Enter metrics manually or import CSV data through a server-side S3 path.
  6. Generate next-cycle insights and convert them into actionable tasks.

The public demo is isolated and deterministic, so judges can inspect this complete workflow without signing in or connecting a social account.

How I built it

CreatorOS is a Next.js App Router application written in TypeScript and deployed on Vercel. The interface uses React, Tailwind CSS, shadcn/ui conventions, lucide icons, and next-intl for English-first localization with secondary Chinese support.

Amazon DynamoDB is the primary backend. I chose it because the product's core reads are organized by workspace, monthly timeline, workflow status, and platform. Those access patterns map naturally to a workspace-scoped single-table model with targeted global secondary indexes.

The table stores profiles, monthly plans, posts, platform variants, draft versions, metrics, insights, tasks, and AI settings. Workspace-scoped primary keys isolate the public DEMO#judge data from Clerk-backed user workspaces. GSI1 supports monthly timeline and metric queries for the calendar and analytics views. GSI2 supports workflow-status and platform-oriented queries.

ElectroDB defines the DynamoDB entities and indexes. A repository layer is the only application layer allowed to read or write DynamoDB, so UI components and route handlers never construct raw table keys. The main persistence path is:

Browser -> Vercel Route Handler -> Repository -> ElectroDB -> Amazon DynamoDB

Status-changing writes use version or timestamp conditions where practical to avoid silently overwriting newer workflow state. AI-generated plans, rewrites, insights, and tasks are validated with Zod before persistence. Server-side services provide scoped Amazon S3 storage, Clerk identity, Resend notifications, and an optional YouTube public-metrics integration without exposing service credentials to the browser.

I deliberately left real social OAuth and auto-publishing out of the H0 version. Keeping those integrations outside the MVP allowed me to focus on a stable, understandable, and testable content operations loop.

Challenges I ran into

The first challenge was making DynamoDB feel intentional rather than attaching it to a finished interface. I had to identify the actual reads first, then design workspace keys and GSIs that supported the dashboard, calendar, post workflow, and analytics views without relying on broad table scans.

The second challenge was supporting both an authenticated product and a frictionless judging experience. Real users need Clerk-backed workspace isolation, while judges need immediate access without a private account. I solved this with a deterministic DEMO#judge workspace that uses the same repository and persistence boundaries as authenticated workspaces.

The third challenge was reliability around generated content. Model responses can be malformed, slow, or unavailable. I added schema validation, typed error categories, safe fallbacks, and clear loading and failure states so the main workflow remains understandable even when an external provider fails.

Finally, scope discipline was a real engineering constraint. Social OAuth, auto-publishing, billing, and complex team permissions were tempting additions, but they would have increased risk without strengthening the core demo. I kept the product focused on the operating loop that judges can see and verify.

What I learned

The biggest lesson was to design DynamoDB from access patterns, not from a list of relational-looking entities. Starting with the questions each screen needs to answer produced a clearer table model and a cleaner repository API.

I also learned that a strong full-stack demo is not just a polished frontend. The UI, persistence model, error handling, identity boundary, and demo data must tell the same story. Conditional status updates and deterministic seeding are not visually dramatic features, but they make the product behave like a real operations system.

Finally, I learned that AI works best as one service inside a workflow rather than as the entire product. Validation, persistence, metrics, and next actions are what turn generated text into an operating system a team could use repeatedly.

How to test it

Open the public CreatorOS dashboard without signing in. Review the 30-day operating view, open the calendar, and select post-01. Inspect the source draft and platform variants, change the workflow status, and save manual metrics. Then open analytics to see how metrics feed insights and actionable tasks.

Built With

Share this project:

Updates