Skip to content
Hooney
한국어

Products · Ended

Social publishing service

A product that put writing and scheduled posting for several social platforms on one screen, which I built alone over about six months to test the market.

6 monthsBuilt alone, from planning to payments and server operations

Period
2025.06 ~ 2025.12
Organization
Firstage
Role
Founder
The scheduling screen of the earlier social publishing service, with publishing settings, per-platform post types, and the schedule in one modal. Account names are blurred.

Core value

Writing and scheduling posts for several social accounts on one screen cut out signing in to each platform to post.

Outcomes

  • About six months of solo work, from planning to payments and server operations
  • Instagram, Threads, Pinterest, and more connected on one screen
  • Posts go out at the scheduled time, and platform sign-ins renew automatically
  • After testing the market, the direction shifted to place-based records

Tech stack

  • React
  • TypeScript
  • Node.js
  • PostgreSQL
  • Redis
  • GCP

Context

This product let people write content for several social platform accounts and schedule it from one dashboard. When writing, media management, account selection, and the publishing calendar live on separate screens, every post means moving between them, and as scheduled posts pile up it gets hard to tell what is still a draft and what has already gone out. From June to December 2025, about six months, I built the planning, frontend, backend, payments, and infrastructure alone and put the product in front of the market.

Decisions and implementation

  • I connected media selection, writing, per-account publishing settings, scheduling, and status tracking into one flow. Recurring posts take an interval, a count, and a time zone, and the same schedule can be viewed as a calendar, a kanban board, or a list across draft, review, approved, published, canceled, and failed states.
  • On the frontend, the Strategy pattern absorbed the differences between social platforms with their own publishing rules (Instagram, Threads, Pinterest) and services such as Canva and Shopify. On the backend, OAuth connections and publishing sat under one contract built with the Strategy and Registry patterns.
  • BullMQ jobs handled scheduled publishing, automatic publishing, and token refresh. Credentials were stored encrypted, and scheduled jobs and retries ran per account, so a failure in one account did not block publishing for the others.
  • Scheduling, CRM, email campaigns, and the workflow builder were separate feature modules. Product tags on images used responsive coordinate mapping, so they stayed in the same spot on any device.
  • I also built subscription payments with billing webhooks, an AI content generation pipeline on the Vercel AI SDK and MCP, and real-time collaboration over WebSocket with a Redis adapter. The infrastructure ran on GCP Cloud Run and Cloud SQL, defined in Terraform with automated deployment.

Current state

After the market test, I moved the company toward place-based records of everyday life and closed this product. The platform integrations above describe what I implemented at the time, not their current approval or operating status. What I learned there about payments, infrastructure, scheduled jobs, and AI integration carries straight into how I build Firstage today.