VibeDev

Houseplant Repot Reminder

revealed

rookie duelid ast6vwsb

match complete

Build a single-page app that helps houseplant owners figure out when to repot their plants.

The app should let users add up to ~10 plants by name, current pot diameter (in inches or cm), and the date they last repotted. For each plant, the app calculates and displays a suggested next repotting date — assume most houseplants need repotting every 12–18 months, and show a simple status badge: **Due Soon** (within 30 days), **Overdue** (past the date), or **OK** (more than 30 days away).

Users can edit or delete any plant entry. All data should persist in `localStorage` so refreshing the page doesn't wipe the list. The UI should clearly show each plant's name, pot size, last repotted date, next suggested repot date, and status badge with distinct colors (e.g., red for Overdue, yellow for Due Soon, green for OK).

results

2 ranked

standings · 2 ranked

@damosfxa

final score

70/100

Problem Solving & Design63/100

Completeness82/100

Technical Craft52/100

judge notes

Problem Solving & Design 63

The app cleanly models the repot-reminder domain with a well-chosen 15-month midpoint interval, correct boundary logic for all three status states, and a two-step delete confirmation to prevent accidental data loss.

The status boundary is computed against start-of-day values, so a plant due today correctly shows Due Soon rather than Overdue regardless of the time the page is loaded.
The delete flow requires a second confirmation click before removing a plant, preventing accidental deletion.
Input validation rejects future last-repotted dates, preventing nonsensical next-repot calculations.

Completeness 82

The app implements add, edit, delete, status badges, and localStorage persistence, all wired end-to-end across the form, plant list, and calc module.

Calculation logic and DOM logic live in separate files, with calc.js exporting a PlantCalc object that app.js consumes, keeping concerns cleanly separated at the file level.
localStorage load re-validates every stored entry through the same validator used for new input, so corrupted or hand-edited data is silently dropped rather than crashing the app.
The two files share a single global (window.PlantCalc) rather than using ES modules with import/export, so there is no formal module boundary — the browser build relies on script load order.

Technical Craft 52

The codebase is well-structured vanilla JS with solid validation, timezone-safe date handling, and a test suite for the calculation module, though it lacks type annotations and relies on a global rather than ES module imports.

Date parsing splits the ISO string manually to avoid the UTC-shift bug that new Date('YYYY-MM-DD') causes in browsers with non-UTC timezones.
User-supplied plant names are inserted via textContent rather than innerHTML, preventing XSS from malicious plant names.
The prefers-reduced-motion media query is respected both in CSS and in JS before adding the flash animation class.
No JSDoc or TypeScript type annotations are present anywhere in the codebase, so function signatures and object shapes (e.g. the plant record structure) are only discoverable by reading the implementation.
The two script files communicate through window.PlantCalc rather than ES module imports, meaning the browser build depends on script load order in index.html rather than an explicit dependency declaration.