SocJam

SocJam is a centralized social media control hub that lets teams draft one post, adapt it for multiple platforms, and publish it from one workspace.

Comment

SocJam - Social Media Management Hub

Inspiration

Creators and social media managers waste hours every week doing manual busywork: tab-switching between X, LinkedIn, TikTok, and Meta to copy, paste, and reformat the exact same post. This constant "context switching" kills productivity. We built SocJam to automate this tedious pipeline, allowing creators to draft once and publish everywhere.

What it does

SocJam is a unified dashboard that automates cross-platform content delivery.

  • Compose Once: Write a single core message, attach media, and select your target platforms.
  • Adapt with AI: Click a button to instantly generate platform-specific variants (e.g., punchy for X, visual for Instagram, professional for LinkedIn). You review it before it goes live.
  • Live Validation: Instantly checks character limits, media counts, and file sizes before publishing to prevent failed uploads.
  • Smart Retry & Scheduling: Publish immediately or schedule via cron jobs. If a post fails on one platform but succeeds on others, our "Smart Retry" only re-attempts the failed targets—preventing embarrassing duplicate posts.

How we built it

  1. Started with the problem, not the tech Before the hackathon, the team pooled 10 different project ideas and pressure-tested each one against a simple question: "Who feels real pain if this doesn't exist?" Social media managers stood out — they routinely rewrite the same post five times, juggle five upload flows, and pray nothing breaks mid-campaign. SocJam won because it combined a clear daily pain point with a technically ambitious AI + integrations angle.
  2. Designed the product in Stitch We used Stitch to design the UI and lock in the core feature set before writing code. That meant mapping out the composer, dashboard, calendar, and settings flows as a team, then iterating until the scope felt tight enough for a weekend but ambitious enough to be impressive. By the time we opened an IDE, everyone already agreed on the user journey: draft once → adapt per platform → publish or schedule → track results.
  3. Split the build around architecture Once the design was solid, we divided work along clean architectural boundaries:
    • Frontend: the unified composer, platform variant cards, calendar, and status dashboard in Next.js 14 + TypeScript + Tailwind/shadcn/ui, mobile-first down to 375px.
    • Backend & data: PostgreSQL + Prisma schema, Auth.js auth, API routes, and the idempotent publish/schedule/retry logic.
    • AI layer: the swappable AIProvider interface and prompt pipeline that generates platform-native copy from a single source of truth (constraints.ts).
    • Platform integrations: the SocialPlatformAdapter registry and real OAuth + publish adapters for LinkedIn and TikTok, plus mock adapters for X, Facebook, and Instagram with deterministic failure simulation.
    • DevOps: Railway deployment, cron route wiring, and encrypted token storage.
  4. Built for the unhappy paths We didn't just build the happy path. We built the partial-failure state machine, retry-only-failed logic, atomic SCHEDULED → PUBLISHING transitions, and idempotency keys from the start — because for a publishing tool, "almost worked" is worse than "didn't work."
  5. Deployed to Railway We containerized Postgres locally with Docker and deployed the app to Railway using the included railway.json config, so migrations run automatically on every deploy. That gave us a live URL to demo and test against real adapters without fighting infrastructure.

Challenges we ran into

  • Taming five different APIs: OAuth flows, media upload endpoints, rate limits, and error codes differ wildly across networks. We unified them behind a single SocialPlatformAdapter contract so the rest of the app thinks in one language.
  • The partial-failure problem: A post can succeed on X and fail on Meta. We built per-target state machines and a retry engine that re-attempts only failed targets — never creating duplicate posts on platforms that already succeeded.
  • Idempotency under every edge case: Double clicks, browser back-resubmits, overlapping cron runs, and revoked tokens all had to result in exactly zero duplicate publishes.

Accomplishments that we're proud of

  • Shipped a working MVP with AI adaptation, scheduling, calendar, per-platform status tracking, and analytics snapshots — in one weekend.
  • Built real LinkedIn and TikTok integrations end-to-end, including OAuth callbacks, encrypted token storage, refresh logic, and media upload.
  • Designed a zero-friction upgrade path from mock to real APIs via the adapter registry.
  • Solved the partial-failure + retry problem the way enterprise tools do, with idempotent keys, atomic DB transitions, and retry-only-failed semantics.

What we learned

  • Adapters are the product: When every platform speaks a different protocol, a clean adapter interface matters more than any UI polish.
  • Idempotency is not a feature you add later: It has to live in the composer key, the publish route, the cron job, and the database transition.
  • AI is only useful if it's constrained: Letting the model loose without validating against real platform limits produces broken posts.

What's next for SocJam

  • Conversational AI Chatbot: Adding an interactive chat UI directly in the composer so creators can brainstorm hooks and refine their tone before generating the platform variants.
  • Autonomous Scheduling Assistant: Expanding the AI to analyze past analytics and autonomously schedule posts for optimal, peak-engagement times across different time zones.

Built With

Share this project:

Updates