Compute exchange front end prompt

A developer has created a production-ready front-end web app for a fictional GPU rental marketplace called Silicon Exchange, built with Next.js, TypeScript, Tailwind CSS, Framer Motion, Recharts, and Zustand. The app features mock data, complex reservation logic with overlap detection and pricing rules, and multiple pages including browse, listing details, dashboard, and compare. All logic is implemented in pure, tested TypeScript functions.

| Create a production-ready, visually stunning front-end web app . | | | GOAL | | | Build a single-page application plus detail routes for a fictional company: | | | "SILICON EXCHANGE" — a marketplace where people rent out idle GPUs and AI | | | accelerators by the hour. Renters browse listings, inspect live utilization | | | charts, and reserve time blocks. | | | FRONT END ONLY. No backend, no database, no auth server, no API keys. All data | | | is mock data defined in code. But the app must behave like the real thing — the | | | reservation logic, the pricing math, and the filter state all have to actually | | | work. | | | TECH STACK use exactly this unless something genuinely breaks | | | - Next.js latest stable, App Router + TypeScript strict mode on | | | - Tailwind CSS | | | - Framer Motion for animations | | | - Recharts for charts | | | - Zustand or React context + reducer for client state | | | - Vitest for unit tests | | | - Zero paid services. npm install && npm run dev is all it should take. | | | MOCK DATA typed, deterministic, defined in /data | | | - 24 listings across at least 5 regions, with realistic chips H100, RTX 5090, | | | M3 Ultra, MI300X, RTX Pro 6000, etc. , memory in GB, TFLOPS, hourly rate in | | | integer cents, and a status of "available" | "maintenance" | "retired". | | | - 30 days of hourly utilization samples per listing 0-100% and power in watts . | | | Generate these from a seeded pseudo-random function so the charts look organic | | | but render identically on every reload. Do NOT use Math.random at render time. | | | - A handful of pre-existing reservations, including at least one that a naive | | | overlap check would wrongly allow. | | | THE HARD PART — these rules must be pure, tested TypeScript functions | | | 1. Overlap detection. A listing cannot hold two reservations whose time ranges | | | overlap. Treat ranges as half-open: a reservation ending at 14:00 and one | | | starting at 14:00 do NOT overlap. Cancelled reservations don't count. | | | 2. Pricing. Billed in 15-minute increments, always rounded UP. Minimum | | | billable block is 1 hour. Any reservation longer than 24 continuous hours gets | | | 10% off every hour beyond the 24th — not off the whole booking. All money is | | | integer cents. Never use floating point for money. | | | 3. Holds expire. A reservation held for more than 10 minutes without being | | | confirmed flips to "expired" and frees its slot. Drive this off a real timer | | | in the UI with a visible countdown. | | | 4. Maintenance blocks new reservations but leaves existing confirmed ones alone. | | | 5. Reservations persist to localStorage and survive a full page reload. | | | PAGES / ROUTES | | | 1 Home — hero, a "GPUs online" counter computed from the real mock data, three | | | feature cards, CTA into browse. | | | 2 /browse — grid of listing cards with working search, region filter, memory | | | range filter, status filter, and sort price, memory, TFLOPS, utilization . | | | Filter state lives in the URL query string and must survive a refresh AND the | | | browser back button. Show an empty state when filters match nothing. | | | 3 /listings/ slug — spec sheet, a 24-hour utilization line chart with a | | | working hover tooltip, a 7-day availability calendar that visually blocks out | | | taken slots, and a reservation form with a live price quote that recalculates | | | as the user drags the time range . Show the pricing breakdown — base hours, | | | rounding applied, discount applied. | | | 4 /dashboard — the user's reservations from localStorage, with countdown | | | timers on held ones, cancel buttons, and a running total spend. | | | 5 /compare — pick up to 3 listings and diff their specs side by side. | | | Selection persists across navigation. | | | 6 404 — custom, on-brand, not the default. | | | DESIGN DIRECTION | | | - Dark-first, with a real light mode toggle that persists and does NOT flash on | | | reload. | | | - Technical-industrial: near-black surfaces, thin hairline borders, monospace for | | | all numbers and IDs, one electric accent color used sparingly. Data-dense but | | | calm. Think a trading terminal, not a SaaS landing page template. | | | - Micro-interactions: hover lift on cards, animated focus rings, smooth section | | | reveals on scroll, an animated gradient behind the hero headline. | | | - Responsive and correct on a phone and on a 4K display. Tables collapse into | | | cards on mobile. Charts stay readable at 375px wide. | | | - Accessibility: full keyboard navigation, visible focus states, semantic | | | headings, labelled form controls, aria labels on icon buttons, and a text | | | summary alternative for every chart. | | | - No stock photography and no external image requests. Every visual is inline SVG, | | | CSS gradients, or generated. The app must render perfectly with the network off | | | after first load. | | | - Two Google fonts, self-hosted via next/font. One for headings, one for body. | | | TESTS must actually pass | | | Write Vitest unit tests covering, at minimum: | | | - Overlap detection, including the half-open boundary case 14:00 end vs 14:00 start | | | - The 15-minute round-up | | | - The 1-hour minimum | | | - The over-24-hour discount applied only to the excess hours | | | - Hold expiry at the 10-minute boundary | | | - The filter/sort reducer returning correct results for a combined query | | | DELIVERABLES — DO NOT STOP UNTIL ALL OF THESE ARE TRUE | | | 1. npm install completes with no errors. | | | 2. npm test runs and every test passes . Do not delete or skip a failing test | | | to make this true — fix the code. | | | 3. npm run build completes with zero TypeScript errors and zero ESLint errors. | | | 4. npm run dev starts and the home page renders the real mock data. | | | 5. A README.md with what it is, how to run it, and a short note explaining the | | | pricing rules. | | | QUALITY BAR | | | Production-ready. No TODO comments, no stubbed functions, no any types, no | | | Lorem Ipsum, no dead buttons. Every control does something. It should look like a | | | high-end product a real company shipped, not a template. If you hit an error, read | | | it and fix it — do not work around it by deleting the feature. | | | Now implement it end-to-end, then verify every item in DELIVERABLES yourself. |