Stuck Stack

Framing the Problem

People go to tech events hoping to get unstuck — but conferences are built around talks, not individual problems. Somewhere in the room is an attendee who can't deploy their Next.js app, another who doesn't understand vector search, another agonising between Firebase and Supabase. And somewhere in the same room is a person who could solve each of those problems in five minutes. They almost never meet, because conventional networking is built on profiles and small talk: ten badge scans, zero problems solved. Attendees leave with the same blockers they arrived with, and organisers have no visibility into what their audience is actually struggling with, so the schedule never adapts to the room.

Idea Explanation

Stuck Stack turns the event into a temporary help marketplace. Instead of "match me with people like me," the unit of interaction is a single, specific blocker: "Here's what I'm stuck on — who can help me solve it in 5 minutes?"

Attendees join an event with just their name (or by scanning a QR code the organiser shares), post a blocker with tags, mark "I'm stuck too" on others' blockers, offer to help, and claim 5-minute help slots. Blockers move visibly across a live board from Open → Matched → Solved. Meanwhile, organisers get a real-time dashboard that aggregates demand: when enough people are stuck on the same theme and helpers are available, Stuck Stack suggests a concrete action — "Create a pop-up clinic: RAG Evaluation Help Desk, Table 3." Scattered individual pain becomes an operational signal the organiser can act on mid-event. A person who unblocks you in five minutes is worth more than ten random badge scans — that's the meaningful interaction at scale this challenge asked for.

Implementation

Stuck Stack is a full-stack Next.js 16 (App Router) application in TypeScript strict mode, with KendoReact as a first-class citizen of the UI and a deliberately layered architecture.

The frontend is a mix of React Server Components for static shells and client components for everything interactive. The public board renders blockers on a Kendo TaskBoard with drag-aware columns and custom blocker cards, with Kendo Badges for "stuck too" and helper counts, a Kendo MultiSelect tag filter, and Kendo Dialogs for posting a blocker and claiming a help slot. The organiser dashboard uses a sortable, filterable Kendo Grid of all blockers, a Kendo Chart comparing demand vs. available helpers by category, a clinic-suggestion panel, and a share panel that renders the event join link as a QR code. The workspace uses Kendo Cards, Dialogs, and a DatePicker for full event CRUD.

The client talks to the backend through SWR polling hooks lib/hooks/*, 3–5 second intervals), which gives the board and dashboard a real-time feel with zero websocket infrastructure — and isolates data fetching so polling can be swapped for SSE/push later without touching components. New activity even triggers toast notifications with sound.

The backend is REST route handlers under app/api/** that stay deliberately thin: they validate input with Zod, resolve the session, and delegate to a service layer lib/services/*) where all business logic and Prisma access lives — toggle semantics for "stuck too," status transitions, the clinic-cluster detection engine, and ownership checks. Data is stored in Postgres (Neon, pooled connections) via Prisma, with a schema covering Organizer → Event → Attendee/Blocker, many-to-many Tags, StuckToo signals, HelpOffers, and HelpSlots.

Auth is intentionally demo-grade but architected honestly: attendees join name-only with an httpOnly cookie; organisers sign up/sign in by unique name and get an HMAC-signed session cookie. Every workspace API and each event's organiser dashboard verifies ownership server-side — client-supplied IDs are never trusted. The production upgrade path (NextAuth magic links) is documented in the architecture doc.

Quality gates run on every PR via GitHub Actions: ESLint, strict typecheck, and Vitest unit tests covering token signing, Zod schemas, taskboard column logic, and the notification differ. Deployment is Vercel with migrate-on-build and a seeded demo event.

Challenges

The hardest problems were the unglamorous ones. KendoReact's TaskBoard and Grid expect their own data models, so we built a mapping layer lib/board/taskboardColumns.ts) translating our domain DTOs into Kendo's task model, with unit tests to keep the translation honest. Making the app feel live without websockets took careful SWR tuning — polling intervals, optimistic mutation after actions, and a notification differ that compares snapshots to fire toasts only for genuinely new activity. Name-only sign-in sounds trivial until you need it deterministic: we enforce case-insensitive uniqueness with a separate nameKey column, because Prisma has no portable insensitive mode across SQLite and Postgres. Migrating from SQLite (dev) to Neon Postgres surfaced pooled-vs-direct connection issues, solved with a directUrl for migrations and a pooled URL at runtime. And the Kendo trial license had to be activated inside Vercel's build step without failing builds when the env var is absent.

Accomplishments

In two days we shipped a complete, deployed product rather than a screen recording of a prototype: two independent auth flows, full event CRUD in an organizer workspace, a live multi-user board, a cluster-detection engine that turns raw "me too" clicks into actionable clinic suggestions, QR-code event joining, real-time-feeling updates with notifications, nine KendoReact component families integrated meaningfully rather than decoratively, CI with tests on every PR, and a written architecture document. The biggest learning was discipline of scope: one specific problem (unsolved blockers at events), one core loop (post → stuck-too → help → solve), and everything else in service of demoing that loop convincingly.

Next Steps

The nearest milestones are replacing polling with SSE push behind the existing SWR hooks (no component changes needed), upgrading to real auth with Clerk magic links while keeping the zero-friction QR join flow, and adding the Kendo Scheduler as a visual help-slot timeline per help-desk table (the swap point is already marked in the code). Beyond that: a clinic lifecycle where organisers accept a suggestion and matching attendees get notified automatically, co-organiser invites on events, and a post-event recap — "who helped me / who I helped" — so five-minute help slots become lasting professional connections. Longer term, blocker data across events becomes a content-planning signal: organisers would know exactly which workshops next year's audience actually needs.