VOUCHR</vouchr>
VOUCHR
Group-buying marketplace — 12 pages, 35+ components, shipped as frontend lead.
12
pages shipped
35+
components
3
agile sprints to handover
SPECIFICATIONS
| ROLE | FRONTEND LEAD |
|---|---|
| YEAR | 2024 |
| TYPE | WEB APP |
| STATUS | handed off |
| STACK | react · typescript · tailwind · three.js · vite · websockets |
| LINKS | — |
| CLIENT | University of Melbourne · COMP30022 |
| SOURCE | handed off to client — NDA |
“The client brief for COMP30022 (IT Project) at the University of Melbourne: build an online marketplace where buyers connect directly to manufacturers and distributors and use collective bargaining to get better deals on big-ticket items.”
A group buying marketplace built for COMP30022 at the University of Melbourne.Buyers create or join buying groups to leverage collective demand, and the system matches them with sellers based on location and product interest, issuing vouchers when enough deposits accumulate.
README.TXT — VOUCHR (6 KB)[full readme →]
== WHAT IS THIS ==
A group buying marketplace built for COMP30022 at the University of Melbourne. Buyers create or join buying groups to leverage collective demand, and the system matches them with sellers based on location and product interest, issuing vouchers when enough deposits accumulate.
== </the problem> ==
The client brief for COMP30022 (IT Project) at the University of Melbourne: build an online marketplace where buyers connect directly to manufacturers and distributors and use collective bargaining to get better deals on big-ticket items. It ran as a client-driven agile project with a five-person team, ending in a real codebase handover.
role & context
Frontend Lead in a 5-person team for COMP30022 (IT Project) at the University of Melbourne. I owned the entire frontend: design system, 12 pages, 35+ components, and backend integration. Codebase handed off to the client under NDA.
Codebase handed off to the client under NDA — architecture, process, and outcomes are described with client details generalized. No repository or internal screenshots are public.
== </my approach> ==
As Frontend Lead I designed and shipped the entire frontend: a design system built from scratch, 12 pages, and 35+ components across 3 sprints, from initial scaffold through full backend integration and client handover. React 18.3 with TypeScript, Vite, and Tailwind, with MarketplaceContext and CartContext wiring global state to the backend API.
== </the story> ==
VOUCHR was built for COMP30022 (IT Project) at the University of Melbourne, a client-driven software project run in agile sprints with a five-person team. The client brief: build an online marketplace where buyers could connect directly to manufacturers and distributors and use collective bargaining to get better deals on big-ticket items.
The solution is a user-driven marketplace where buyers declare what they want (product, quantity, price target) and the system intelligently matches them with sellers who can fulfill within their service areas. Buyers create or join buying groups (e.g. "4K TV for $1,299"), put down deposits, and when enough accumulate the system automatically issues vouchers for redemption.
As Frontend Lead, I designed and shipped 12 pages and 35+ components across 3 sprints, from initial scaffold through to full backend integration and client handover. The project included dual buyer/seller dashboards, analytics pages with charts and demographic data, a buying group management system, and a Three.js 3D landing animation.
== </architecture> ==
The frontend runs on React 18.3 with TypeScript, Vite, and Tailwind CSS. State management uses React Context API. MarketplaceContext handles global marketplace state and CartContext manages the shopping cart, both connected to backend API endpoints.
The component architecture is built from 15-20 base UI components (Button, Card, Badge, etc.) that compose into larger features like BuyingGroupCard, DashboardStatsCards, and OfferAcceptanceModal. 35+ components total across 12 pages: landing page with Three.js 3D animations, login/signup with OAuth2, marketplace and seller dashboards, buyer and seller analytics, buying group browsing and creation, profile management, notifications, and settings.
Backend integration happened in Sprint 3. All GET and POST endpoints connected, form submissions wired to the API, and real-time data retrieval made functional. The matching system filters by seller footprint and buyer location as the primary filter, then notifies only relevant parties.
== </key features> ==
Design system from scratch
15-20 base UI components composing into larger features, matching the Figma prototypes exactly · Satoshi typography, color scheme, spacing, and interaction patterns · rather than adopting a component library.
Buying group flow
Buyers declare product, quantity, and price target, create or join groups, put down deposits, and the system automatically issues vouchers when enough accumulate.
Dual buyer/seller dashboards
Separate marketplace and seller dashboards plus analytics pages with charts and demographic data, all on the same component base.
Location-first matching
The matching system filters by seller footprint and buyer location as the primary filter, then notifies only the relevant parties.
Real-time WebSocket updates
Buyers and sellers get live notifications on group activity without polling.
Three.js landing without the cost
A 3D landing animation differentiates the product from typical marketplace UIs while Vite's optimized bundling keeps load performance intact, with motion tuned to 60fps from 375px mobile up to 1920px desktop.
== </key decisions> ==
DECISION 01
The biggest frontend decision was building the entire design system from scratch rather than using a component library. With 12 pages and 35+ components, having full control over the UI meant every element matched the Figma prototypes exactly: typography (Satoshi font family), color scheme, spacing, and interaction patterns.
DECISION 02
Three.js on the landing page was a deliberate choice to differentiate the product from typical marketplace UIs. It added visual impact without compromising load performance thanks to Vite's optimized bundling.
DECISION 03
Sprint 3 introduced a new pricing model and group auto-deletion at max capacity. Both required touching nearly every component in the buying group flow. Keeping components small and composable from Sprint 1 meant these sweeping changes could be made without rewriting the entire UI.
DECISION 04
The responsive design targets mobile (375px+), tablet (768px+), and desktop (1920px+), with motion animations optimized to run at 60fps. WebSocket notifications ensure buyers and sellers get real-time updates on group activity without polling.
== </what i learned> ==
Owning the design system end to end was the biggest frontend decision · with 12 pages and 35+ components, full control was the only way every element matched the Figma prototypes exactly.
Keeping components small and composable from Sprint 1 is what made Sprint 3 survivable: a new pricing model and group auto-deletion touched nearly every component in the buying group flow without a rewrite.
Visual differentiation and performance aren't a trade-off if the bundling strategy is right · Three.js on the landing page added impact without compromising load.
react · typescript · tailwind · three.js · vite · websockets
handed off
[codebase handed off to client — NDA]