Skip to content
Hooney
한국어
Products

Personal productsDiscontinued

Social publishing service

I built a service for writing and scheduling posts across social accounts. After about six months of development and market testing, I shifted toward recording everyday life.

6 monthsBuilt alone, from planning to payments and server operations

Period
2025.06 ~ 2025.12
Organization
Firstage
Role
Founder
Key features
Users could choose an account and publishing time, then track scheduled posts from one screen.
Work and results
  • About six months handling planning, development, payments, and server operations
  • Instagram, Threads, Pinterest, and more connected on one screen
  • Scheduled publishing and automatic account token refresh
  • After testing the market, the direction shifted to place-based records
Tech stack
  • React
  • Node.js
  • PostgreSQL
  • Redis
  • TypeScript
  • GCP

Context

From June to December 2025, I developed a service for writing and scheduling content across social accounts. I handled planning, frontend, backend, payments, and infrastructure over about six months of market testing.

When writing, media management, account selection, and scheduling are split across screens, even one post requires moving between them. I brought those tasks together and made it possible to distinguish drafts, scheduled posts, and published posts.

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.

Screen gallery

Archived service screen: select saved images and videos, write a post on the left, and choose the publishing accounts on the right.
Archived service screen: scheduled posts arranged by date in the monthly calendar.
Archived service screen: a kanban board separates draft, review, approved, published, canceled, and failed posts.
Archived service screen: publishing schedules and processing states for multiple posts in one list.