$ loading
Your favorite pothos is bursting out of its pot and you need to know exactly what size pot to graduate it into — too big and the roots will rot, too small and it'll be cramped again in weeks. Build a single-page widget where a user enters the **current pot diameter** (in inches or centimeters) and the app instantly displays: - The **recommended next pot size** (typically 1–2 inches larger for most houseplants) - A **visual comparison** showing the old pot vs the new pot as simple circles or rectangles drawn on the page - A short tip blurb (e.g. 'Choose terracotta for moisture-loving roots!' or 'Go ceramic for slower drying soil') that changes based on the size range selected The user can also pick a **plant category** from a short dropdown (succulents, tropical, leafy greens, orchids) which adjusts the sizing logic — succulents prefer only ½-inch bumps, orchids stay snug, tropicals like a full 2-inch jump. All state lives in the page with no backend. The interaction is: type a number, pick a category, see the recommendation and visual update immediately.
standings · 2 ranked
commits
loading…
Problem Solving & Design C
The sizing logic correctly implements per-category increments, unit conversion, orchid root-cap logic, and a range display, with a history panel and localStorage persistence rounding out the experience.
Completeness B
Core features are all present and working, but the result panel never surfaces validation errors as visible user-facing messages — the error state falls back to a stale or empty view rather than explaining what went wrong.
Technical Craft C
Logic is cleanly decomposed into named functions and localStorage access is wrapped in try/catch throughout, but the single-file structure, absence of type definitions, and no automated tests leave the codebase harder to extend or verify.