RainPocket

RainPocket desktop calculator and storage comparison
RainPocket mobile layout

Inspiration

A small roof can send a surprisingly large volume of water toward a drain during one storm. I wanted a quick, transparent way to test the first question in a campus rain-garden discussion: how much temporary storage would a chosen rainfall event need?

What it does

RainPocket lets a user enter roof area, design rainfall, runoff coefficient, porous storage-layer depth, and void fraction. It converts the inputs into an estimated runoff volume, a corresponding garden storage area, and liters to store. A three-bar comparison shows how smaller areas would capture less of that event volume. Every result updates when the user calculates a new plan.

The default example is 120 m² of roof, 30 mm of rain, and a 0.85 runoff coefficient: 3.06 m³ of runoff. A 15 cm porous layer with a 0.30 void fraction holds 0.045 m³ per square meter, so the estimated area is 68.0 m².

How I built it

The app is original HTML, CSS, and JavaScript written during Hack Atlantic. It has no runtime packages, account, backend, tracking, or external dataset. The arithmetic module separates unit conversion and validation from the UI. The chart is rendered from the same calculation, caps captured volume at the event runoff, and has a text alternative. The layout works on desktop and mobile.

I used OpenAI Codex for planning, implementation, and QA, and OpenAI image generation for a visual concept. The released interface and graphics are native code, not a screenshot pasted into a page.

Challenges

The first visual concept showed a storage area that did not match its own formula. I corrected the sample to 3.06 ÷ (0.15 × 0.30) = 68.0 m² before implementation. I also changed “ponding depth” to “storage layer depth” because void fraction describes porous media rather than open ponding water. At a narrower desktop width, metric labels crowded each other; I let them wrap and adjusted the type scale.

Accomplishments and learning

The shipped screen has a consistent example, bounded input validation, repeatable unit tests, and a working input-to-result flow. I learned to keep the physical assumption visible: this is a one-event porous-storage estimate. It does not model infiltration, overflow, groundwater, or local engineering standards.

What's next

I would add a site-specific infiltration test, an overflow path sketch, and local design-standard checks before anyone used this for construction. I would also test the wording with campus facilities staff.