Personal Project Case Study
ParkPulse predicts how busy a UK theme park will be on any given day and turns that prediction into a personalised, weather-aware itinerary.
Product focus
UK theme park crowd prediction, multi-park comparison, and a personalised, weather-aware day planner.
Architecture
TypeScript monorepo with an Express + Zod prediction API, a React + Vite + Tailwind planner UI, and a self-calibrating prediction log.
Build priority
Transparent, explainable predictions over black-box scoring — every crowd index ships with a weighted factor breakdown and a confidence value.
ParkPulse is a planning tool for UK theme park visitors who want to pick the quietest day, the right park, and the smartest order to ride attractions in.
Instead of guessing whether a Tuesday in October will be quieter than the Saturday after, ParkPulse takes a park and date and returns a 0–100 crowd index, a confidence value, an hourly crowd curve, per-ride queue estimates, and a personalised itinerary for the day.
The product spans three planning modes — single date, date range, and multi-park — all backed by the same scoring engine, so a user can move from "is this day busy?" to "which day in this window is quietest?" to "which park should I pick?" without changing tools.
UK theme park visitors currently rely on rough rules of thumb — "avoid school holidays", "pick a Tuesday", "check the weather" — without any tool that combines those signals into a single, defensible prediction for a specific park on a specific date.
ParkPulse solves that by unifying operating calendars, school and bank holidays, weather forecasts, seasonal events, ride launches, and pricing tiers into one weighted scoring engine, then exposing every contributing factor so the user can see why a day was scored the way it was.
ParkPulse was built around a small set of explicit product principles.
ParkPulse is a TypeScript monorepo organised as an npm workspace with a server (Express prediction API) and a web (React + Vite planner UI) package.
The API exposes a small surface of typed POST and GET endpoints under /api/predictions, validates every request body with Zod, and composes its predictions from a set of focused service modules — one per signal — that each contribute weighted factors to the final score.
The web app is a single-page React 18 + Vite application styled with Tailwind CSS and DaisyUI, using Radix Themes and Lucide icons for primitives. It drives all three planning modes (single date, date range, multi-park) from one UI shell.
The scoring engine combines a per-park baseline with weighted contributions from each signal module, then applies learned calibration multipliers before returning a 0–100 crowd index, a confidence value, and a factor breakdown.
Every demand signal — bank holidays, school holidays, weather, events, ride launches, daylight, pricing — lives in its own typed module under server/src/services. The scoring module composes them, which keeps each signal independently testable and makes it cheap to add or replace one without touching the rest.
Rather than returning a single number, every prediction ships with an explanation containing a summary and a list of weighted PredictionFactor objects. The API never produces a score without also producing the reasons for that score.
A POST /record-actual endpoint lets observed crowd levels be matched back to the prediction that produced them. The prediction log feeds a calibration module that adjusts future weight multipliers, so the system improves with use rather than depending on a one-shot training run.
A crowd index alone does not help a visitor plan their day. The itinerary planner consumes the same prediction (crowd index, hourly curve, weather, school-holiday flag) plus user preferences and produces a slot-by-slot ride plan, which is what the user actually came for.
The Express app is exported from server/src/app.ts and consumed both by the local dev server (server/src/index.ts) and by a Vercel serverless function (api/index.ts that simply re-exports the app). vercel.json rewrites /api/* and /health to that function and serves the Vite build for everything else, so one app definition powers both environments.
Premium gating is implemented as Express middleware with a stripPremiumFields helper, so route handlers stay focused on prediction logic and the gating model can be swapped for a real payment provider without rewriting endpoints.
I designed and built ParkPulse end-to-end: the product concept, the source register and ingestion plan, the weighted scoring model, the per-signal service modules, the Express + Zod API, the React + Vite planner UI, the itinerary planner, the calibration loop, and the Vercel deployment configuration.
The work spans product strategy (deciding which signals matter and how to combine them), backend engineering (typed services, validation, logging, and serverless deployment), and frontend engineering (a single-page planner that exposes three different planning modes through one cohesive UI).
No single input — weather, school holidays, events — predicts crowds on its own. The challenge was assembling a weighted model where each signal contributes a transparent, bounded factor, and where the final crowd index can be defended by pointing at the factor breakdown rather than at a black-box number.
Predicting a crowd index is only half the job; the user actually wants to know which ride to do at 10am. The itinerary planner had to consume the hourly curve, weather, school-holiday context, and a small set of user preferences (day type, pace, ease-in, lunch break, skip and must-ride lists) and produce a coherent slot-by-slot plan.
Static weights drift. Building a JSONL prediction log, a record-actual endpoint, and a weight-calibration module meant the system could learn from observed reality instead of depending on a one-time tuning pass.
The Express app needed to run as a normal Node server during development and as a Vercel serverless function in production without duplicating route definitions. Splitting app, server entrypoint, and serverless adapter into three thin files (app.ts, index.ts, api/index.ts) solved that cleanly.
Quality work in ParkPulse is concentrated in the logic-heavy parts of the prediction engine, where errors are hardest to spot by eye.
ParkPulse is set up for low-cost public deployment on Vercel, with the static planner and the Express API served from the same project.
A vercel.json file rewrites /api/* and /health to the serverless adapter and serves the Vite build for everything else, so the whole product ships as a single deployment.