VibeDev

Pizza Slice Party Splitter

revealed

rookie duelid hcnz39ah

match complete

You're at a pizza party and nobody can agree on how to fairly divide the bill when people ate different numbers of slices. Build a single-page app where the user enters the total pizza cost, the number of people at the table, and how many slices each person ate. The app instantly calculates and displays how much each person owes based on their slice consumption — no more awkward guessing or overpaying. Each person entry should show their name (or a default label like "Person 1"), slices eaten, and their calculated share in dollars. The total slices eaten and running cost breakdown should update in real time as values change. Keep it simple: add/remove people, update slice counts, and see everyone's share update immediately.

standings · 2 ranked

@yinn

final score

74/100

Problem Solving & DesignB+

CompletenessB

Technical CraftF

commits

loading…

judge notes

Problem Solving & Design B+

The app solves the brief's fairness problem cleanly, adds a compare-to-even-split mode and rounding transparency, and handles edge cases like zero slices and single-person tables gracefully.

When no slices have been entered the app falls back to an even split and tells the user why, rather than showing $0.00 for everyone.
The compare mode labels each person's row with how much they save or overpay versus a naive even split, making the fairness argument visible.
Rounding is explained inline — the note tells users exactly how many people cover the rounding penny so the total adds up precisely.

Completeness B

All core brief features are implemented end-to-end in a single well-structured file, with persistence, a compare mode, and a copy-to-clipboard export as extras.

Slice-proportional calculation uses the largest-remainder method so shares always sum to the exact total, with a clear fallback to even split when no slices are entered.
State is persisted to localStorage on every change, so the breakdown survives a page refresh without any server.
The summary bar updates live with people count, total slices, price-per-slice, and allocated total, giving a running cost breakdown as the brief requires.
No error is ever surfaced to the user — if localStorage throws, the catch block silently swallows it and the user sees no indication that their data was not saved.
There is no loading or pending state of any kind; while the app is synchronous and fast today, any future async path would have no UI hook to show progress.

Technical Craft F

The implementation shows strong CSS design-token discipline, accessible markup, and animated feedback, but lives entirely in one HTML file with no modules, no type definitions, and no automated tests.

Design tokens are declared once in :root and overridden for dark mode, giving a consistent visual system across colours, radii, and shadows without repeated literals.
Every interactive control carries an explicit aria-label, and the summary bar uses role=status with aria-live=polite so screen readers announce updates.
The :focus-visible rule provides a keyboard focus indicator scoped to keyboard navigation only, avoiding the outline suppression common in single-file apps.
All logic — state, rendering, calculation, persistence, and event wiring — lives in a single IIFE with no modules or exported functions, making the code hard to test or reuse in isolation.
There are no type definitions or schemas anywhere; the shape of a person object and the calc return value are implicit, so callers have no contract to check against.
There are no automated tests; the largest-remainder algorithm and the compare-mode delta logic have no assertions a machine can run to catch regressions.