Skip to content
Work
Live app
Case file 01Independent build · 2026

TaskFlow.

A chat-native work OS for the decisions that usually get lost between messages.

Role
Product design + full-stack
Scope
UI, schema, realtime, auth, deploy
Stack
Next.js 14, React 18, Express, Socket.IO, PostgreSQL, Prisma
Status
Live on Render + Neon
TaskFlow dashboard showing daily goal, DSA progress, recent activity, and milestones
Dashboard · synthetic demo account · local production buildFree-tier demo · first load may take a minute
3
services + proxy
62
Prisma models
116
DSA questions
2
OAuth providers

01 / The brief

The decision is in the message. The work is somewhere else.

Teams make decisions in chat, then rebuild them as tasks, docs, and reminders in other tools. The context gets lost at the handoff. TaskFlow takes the opposite approach: the conversation is the workspace, and every artifact stays attached to the message that created it.

The constraints were self-imposed but real: one free-tier container, one relational schema, and realtime without a separate queue or cache. That forced a small number of strong primitives instead of a wide, shallow feature list.

The result is a product where a message can become a task, a poll, a brief, or a practice room without leaving the conversation. The interface stays quiet; the context stays attached.

01

One deploy

Next.js, Express auth, Socket.IO, and a Node proxy share one 512 MB Render instance. Every choice had to fit that budget.

02

One schema

62 Prisma models — channels, tasks, notes, DSA progress, billing — share PostgreSQL as the source of truth.

03

Realtime, no queue

Socket.IO carries chat and presence directly. It works for this build, not for a cluster. That ceiling is documented, not hidden.

Keep the context attached to the commitment.

02 / The build

One conversation, three kinds of follow-through.

The product is broad, but the loop is narrow: say something, decide it, then keep the evidence in the same place.

TaskFlow chat with the slash command menu open showing /poll, /task, /brief, and /dsa
Channel general · slash command menu · synthetic workspaceFree-tier demo · first load may take a minute

01 / Conversation → commitment

Commands, not context-switching.

A message can become a task, a poll, or a channel brief without leaving the conversation. The slash menu is the smallest possible interface for the biggest source of lost work.

  • /task creates an assigned task from a message; /poll closes a decision in-channel.
  • /brief keeps the channel's current summary beside the conversation.
  • Threads, reactions, pins, mentions, files, and search preserve the surrounding context.
TaskFlow DSA practice page showing 116 questions, 62 completed, difficulty and topic filters, and question cards
DSA practice · 62 of 116 solved in the synthetic accountFree-tier demo · first load may take a minute

02 / Practice → deliberate work

A practice system inside the team space.

DSA practice is not a separate app. It shares the same account, workspace, and realtime layer. /dsa opens a co-working room from chat and records attendance and time.

  • 116-question bank across difficulty and topic, with progress, streaks, and history.
  • CSV and LeetCode import/export, per-question attempts, and time tracking.
  • Live co-working rooms with attendance logs, opened from the conversation.
TaskFlow notes view with a weekly review document and a list of recent workspace notes
Notes · shared workspace · synthetic dataFree-tier demo · first load may take a minute

03 / The quiet surface

Focus, notes, and the shape of a week.

The rest of the day lives on the same data model: notes, a calendar, focus rounds, achievements, and a leaderboard. The dashboard shows the next action, not every possible action.

  • Daily goal, focus rounds, streaks, and recent activity from one account.
  • Organizations with RBAC, invites, Google and GitHub OAuth, and EN/TE locales.
  • 62 Prisma models behind one migration path.

03 / The system

The interesting part is what is not running.

No Redis. No queue. No separate frontend deployment. The free-tier constraint turned the architecture into a routing problem: three services behind one proxy, one container, one database.

01

Browser

React · WebSocket

02

Node proxy

$PORT · routing

03

Next.js / auth / socket

one container, three processes

04

PostgreSQL

Neon · Prisma · 62 models

One 512 MB instance · one pooled Postgres endpoint at runtime · a direct endpoint for migrations.

01

Shared deploy, isolated processes

A small Node proxy sends /socket.io to Socket.IO and everything else to Next.js. Next API routes call the Express auth service server-side over localhost.

Trade-off · One failure domain; one deploy and no cross-service network hops.

02

One database contract

The app, auth service, and socket server share one Prisma schema. Runtime traffic uses Neon's pooled URL; migrations use the direct URL.

Trade-off · Schema coupling in exchange for no sync layer and one source of truth.

03

Realtime with a known ceiling

Socket.IO runs in-process with presence and message fan-out. There is no Redis adapter, so this is deliberately a single-instance design.

Trade-off · The next piece of work is horizontal fan-out, not a hidden assumption.

04 / Status

What is live, and what is not.

A demo is more useful when its edges are visible. This is the current state of the build, including the parts I would change with a larger budget.

Shipped

  • Public live build on Render Free + Neon Free.
  • Google and GitHub OAuth with verified-email account linking.
  • Chat, tasks, polls, briefs, threads, reactions, files, mentions, search, and calls.
  • Notes, mind maps, calendar, focus, leaderboard, achievements, notifications, invites, RBAC, and EN/TE locales.
  • Typing game, onboarding, and billing in test mode.
  • DSA practice with 116 questions and live co-working rooms.

Known limits

  • The free tier sleeps; the first request can take up to a minute.
  • The public database has no synthetic demo account, so sign-in is required.
  • Uploads are ephemeral on the free instance.
  • Socket.IO is single-node; there is no Redis adapter yet.
  • Billing runs in test mode and is not presented as a live payment system.

See it running.

The live build is the same product shown above. The screenshots use a local, synthetic workspace so the public database stays clean.

Open live app Next case file