← Back to selected work
01 / Engineering storyIndependent product · End-to-end ownership

Pushwing

From an idea to a published story.

An AI-connected publishing system for YouTube and Instagram. I built the dashboard, API, hosted MCP server and the workers behind every publishing job.

ReactTypeScriptMCPBackground jobs
React + TypeScriptDashboard and reusable UI
API + MCPTwo interfaces, shared services
Async by designPostgreSQL-backed publishing jobs
01 / The challenge

A product problem, not just a screen.

Publishing from an AI client is more than an upload call. The user needs to connect the right account, understand what will happen, and follow a job that continues after the request has finished. Those states need to make sense in a dashboard as well as through MCP tools.

What I owned

I built Pushwing from scratch: the React/TypeScript dashboard, API, hosted MCP server, shared services, provider integrations and background workers. My frontend work covers account connections, publishing jobs, usage and activity.

The system, made visible

Follow a publishing workflow

Conceptual map of the implemented components. Select a step to explore it; this is not a live publishing request.

  1. 01Connect
  2. 02Request
  3. 03Process
  4. 04Inspect
01

Connect

OAuth connects a provider account. The React dashboard exposes account-connection state.

02

Request

A dashboard/API request or an MCP tool invokes the publishing workflow through shared services.

03

Process

PostgreSQL-backed pg-boss jobs and background workers perform the asynchronous provider work.

04

Inspect

Publishing-job, usage and activity interfaces expose the work to the user, supported by audit logging.

02 / Engineering decisions
01

Make server state a first-class UI concern

What I built

I used TanStack Query for dashboard data and an OpenAPI-generated API client, alongside reusable interface components.

Why it matters

Account connections and publishing jobs are changing server state. A typed client keeps the API contract explicit; query-based data handling gives those screens a consistent foundation.

02

Share the workflow, not just the types

What I built

The dashboard/API and MCP tools use a shared service layer for account, media, publishing-job and provider operations.

Why it matters

A user can enter through a visual interface or an AI client. Shared services put the core publishing behaviour behind both entry points.

03

Separate the request from the publishing work

What I built

I implemented PostgreSQL-backed jobs with pg-boss, provider integrations, OAuth, token-refresh workers and audit logging.

Why it matters

The frontend needs a job to follow, rather than tying the whole experience to one long-running HTTP request. Usage and activity views make the background work understandable.

03 / Evidence & results

A working publishing product with a shared foundation for dashboard and AI-client workflows.

The public product and existing walkthrough are available below. Pushwing is in early access: YouTube uploads remain private while API review is pending, and Instagram access is invite-only. No adoption or performance benchmark is claimed here.

Pushwing public product website
Public product website · Early access

See the product in motion

The existing public Pushwing walkthrough. Play on demand.

Open walkthrough ↗
Explore Pushwing ↗
Keep exploringAgenvik↗

Conversations with a memory.