VibeDev

Sourdough Starter Diary

revealed

rookie brawlid vgzkr10o

match complete

You're a home baker obsessed with your sourdough starter — that living jar of wild yeast that needs daily attention. Build a single-page app that helps you track every feeding session for your starter(s).

Each log entry should capture: the date and time of feeding, the flour-to-water ratio used (e.g. 1:1:1), the starter's nickname, a quick activity rating (sluggish / normal / very active), and an optional note (smell, appearance, temperature).

The app should display a scrollable feed of past feedings in reverse chronological order, show the time elapsed since the last feeding for each starter, and let the user maintain multiple named starters (e.g. 'Doughlores', 'Yeastie Boys'). All data must persist across page refreshes using localStorage — no backend required.

Include a simple summary bar at the top showing each starter's name and how many hours ago it was last fed, so a bleary-eyed baker can check at a glance whether it's time to feed again.

standings · 4 ranked

@devontedan

final score

77/100

Problem Solving & DesignA

CompletenessB+

Technical CraftC

commits

loading…

judge notes

Problem Solving & Design A

The app maps cleanly to the brief's domain — multiple named starters, per-starter status chips, reverse-chronological feed, and inline starter creation all work together coherently.

A 30-second interval tick forces re-renders so relative timestamps stay current without any user interaction.
New starters can be created inline from the feeding form without a separate flow, reducing friction for first-time use.
Feedings are kept sorted by fedAt on every addition, so manually back-dated entries appear in the correct chronological position.
There is no way to delete a starter or a feeding entry; once logged, a record is permanent, which will become unwieldy over time.
Deleting a starter leaves its feedings orphaned; FeedList handles this by showing 'Starter Dihapus', but since deletion is not implemented the orphan path is unreachable and the stale data accumulates silently.

Completeness B+

Core brief features are all implemented end-to-end, but storage errors are silently swallowed on read and localStorage failures on write are not surfaced to the user in the current flow.

The empty state in FeedList renders a helpful prompt when no feedings exist, guiding new users to log their first entry.
The summary bar shows a colour-coded status dot per starter, distinguishing overdue (>24h), warning (≥12h) and healthy states at a glance.
When localStorage.getItem throws (e.g. in a restricted context), safeGetItem silently returns the default value with only a console.warn — the user sees no indication that their data could not be loaded.
There is no loading indicator of any kind; the app renders immediately from an empty state before the useEffect hydration runs, which can briefly show the empty-state UI even when data exists.

Technical Craft C

The codebase is cleanly modularised with well-named utility functions and PropTypes on every component, but has no TypeScript types or automated tests.

Storage operations are wrapped in safeGetItem/safeSetItem with explicit error-type discrimination, preventing quota or privacy-mode exceptions from crashing the app.
Activity buttons use aria-pressed to communicate toggle state to assistive technology.
The entire design token set — colours, shadows, radii — is declared once in CSS custom properties and reused throughout the stylesheet.
No automated tests exist anywhere in the repository; utility functions like formatTimeAgo and getHoursAgo are untested despite being central to the app's correctness.
The project uses no TypeScript or explicit schema definitions; prop shapes are declared with PropTypes at runtime only, leaving data structures implicit at authoring time.
App.css contains a large block of unused Vite scaffold styles (hero, ticks, next-steps) that were never removed, adding dead code to the bundle.