QuickHub — Walk-in Counter Platform

Summary

QuickHub is a walk-in shipment counter platform born from a multi-phase internal company hackathon — and the project that earned 1st Place in the final implementation round. What made this win meaningful wasn't just the product. It was doing it as Tech Lead Fullstack: owning the PRD, directing design, coordinating the team, and shipping production-grade code simultaneously — without dropping either role.

This is also where AI-assisted development became a deliberate, systematic workflow for the first time — GPT for ideation, Claude Code for intensive implementation.

Context & Requirements

The hackathon ran across multiple structured phases — not a single weekend sprint, but a rigorous multi-month program designed to filter ideas, sharpen thinking, and reward execution:

1. Ideation Phase — Open submission across the company. Over 100 ideas entered.
2. Selection Phase — Ideas evaluated for business impact and feasibility. Best ideas advanced.
3. Bootcamp Phase — Shortlisted teams refined their concepts, validated with stakeholders, and built foundational specs.
4. Implementation Phase — 12 teams entered. 3 reached the finals. 1 won.

The problem space: walk-in service counters were slow, error-prone, and opaque. Counter staff juggled multiple tools. Customers waited without visibility. Managers had no real-time operational picture. The mandate was to fix the end-to-end counter experience — not just one part of it.

Architecture

The stack was chosen for speed of development, operational simplicity, and the right tool for each concern:

Tech Stack:

Why polling instead of WebSocket? A deliberate tradeoff. For a queue display refreshing every 3 seconds, full-duplex WebSocket connections introduce deployment complexity (sticky sessions, connection management) without meaningful UX benefit. Redis holds queue state in memory; polling is fast, stateless, and straightforward to scale. Right tool, right constraint.

Leading End-to-End

The Tech Lead Fullstack role in a hackathon context means something specific: the lead doesn't just delegate — they stay in the code while also owning every upstream and downstream decision. That's the dual burden this project carried.

What "end-to-end" looked like in practice:

• Analytical process: Translated the problem space into a structured PRD — defined user personas (counter staff, customers, managers), mapped pain points, and set measurable success criteria before a line of code was written
• Design direction: Collaborated on UX flows and UI structure, ensuring the counter app was optimized for speed (staff handle 10+ transactions/hour), the kiosk was self-explanatory, and the queue display was readable at distance
• Team coordination: Ran parallel workstreams across frontend, backend, and infrastructure — sequenced dependencies, resolved blockers, kept delivery on track through bootcamp and implementation phases
• Hands-on implementation: Contributed directly to codebase — not in a supervisory capacity, but shipping features alongside the team

Managing time across these responsibilities — without the coding output dropping and without the team losing direction — was the real challenge this project tested.

AI-Native Development

QuickHub was the first project where AI tooling became a structured part of the workflow, not an occasional assist:

• GPT for ideation: During the brainstorming and bootcamp phases, used GPT to stress-test ideas — rapid scenario generation, edge case exploration, competitive analysis framing
• Claude Code for implementation: During the implementation phase, Claude Code was used intensively — scaffolding Golang handlers, generating Vue component structure, writing MongoDB query patterns, and accelerating iteration speed significantly

This wasn't "AI helped me write some boilerplate." It was the first systematic application of AI pair programming across the full development lifecycle. The speed gain was real and measurable — and it directly influenced how this team competed against the other finalists.

Key Features

1. Digital Queue Management

2. Counter Staff Dashboard

Purpose-built for high-throughput environments:

• Pre-loaded customer data from queue registration — no re-entry
• Quick actions for common transaction types
• Keyboard shortcuts for power users processing back-to-back transactions
• Status indicators showing current queue depth and counter load

3. Queue Display System

Large-format display for waiting areas:

• Live serving numbers updated every 3 seconds
• Estimated wait time based on current queue depth
• Service announcements and counter status
• Designed for readability at 5–10 meter viewing distance

4. Customer Kiosk

Self-service entry point:

• Digital queue registration with optional shipment pre-fill
• Live queue position after registration
• Package drop-off scanning
• Receipt and ticket printing

Results & Metrics

Competition outcomes:

• Won 1st Place in the final implementation phase (3 teams)
• Advanced through all phases: 100+ ideas → selection → bootcamp → 12 teams → finals → 1st
• Recognized for both technical quality and business impact clarity

Operational improvements delivered:

• Transaction handling reduced from 10+ minutes (fully manual) to under 5 minutes
• Customer queue visibility introduced for the first time — previously zero
• Manual paper-form data entry eliminated entirely
• Counter managers gained a live operational dashboard replacing anecdotal throughput tracking

Team & Leadership

Led a team of 3 engineers across the full hackathon arc — from first concept through final demo:

• Structured the analytical process: defined the problem, wrote the PRD, established success criteria
• Directed UX and design decisions in collaboration with team
• Sequenced implementation workstreams to avoid dependency bottlenecks
• Presented the live demo to the judging panel and answered technical questions under pressure
• Maintained personal coding contribution throughout — leadership didn't reduce the individual delivery expectation

The challenge wasn't any single technical problem. It was doing all of this in parallel, under competition pressure, while the other finalist teams were doing the same.

What I Would Improve

Push notifications over polling — the 3-second poll works well, but for the customer-facing kiosk, native push or SSE would allow proactive "you're next" notifications without the customer needing to watch the display.

Analytics layer — the admin view shows real-time queue state, but historical throughput analytics (peak hours, average handle times by counter, staff efficiency trends) would give managers actionable data for scheduling and training decisions.

Role-based admin — a single unified admin role covers the current use case, but production rollout would benefit from scoped permissions: counter staff, floor supervisor, and operations manager each need a different view of the same data.

---

This project is a benchmark in how I work under pressure — leading without stepping back from the code, and shipping with a team instead of just directing one. It set the standard for how I approach every complex delivery since.