-
-
Home Screen
-
Select landscape category
-
Select plant type
-
Select a hose for at-home flow test to guide amount of water
-
Hose flow results after real-life backyard host flow test
-
Provide zip code for microzone ETo mapping to guide recommendation
-
Add surface area and soil type
-
Sanity check reality - on-the-ground observation is the gold-standard
-
Get accurate watering cycle length and number of cycles
-
Explain why to only water this much with user's hose flow, prevent runoff and over-watering
Project overview fields
Project name
WhenToWater?
Tagline
Irrigation controller intelligence for the ordinary hose in your hand and the human doing the watering.
Short description
WhenToWater? turns California irrigation evidence, plant demand, watered area, recent conditions, and a homeowner's measured hose flow into one practical answer: when to water and when to turn off the hose.
Category
Apps for Your Life
About the project
Inspiration
Most homeowners do not have an irrigation controller or professional irrigation training. They are standing outside with a hose, often in sun glare, trying to decide how much water a plant needs before impatience turns into overwatering, puddling, or runoff.
My irrigation coursework and certifications taught me that this apparently simple decision depends on a chain of evidence: local reference evapotranspiration, plant or crop demand, watered area, delivery rate, soil and runoff behavior, and recent rain or watering. Controllers perform versions of this work for installed irrigation systems. WhenToWater? is intended to bring that intelligence to the person holding an ordinary hose, without requiring the cost and complexity of a professionally designed irrigation system.
The product principle is simple: homeowners should not have to read six formulas. They should receive one trustworthy action and be able to inspect the evidence only if they want to.
What it does
The Build Week submission demonstrates one complete California homeowner path:
- Choose Vegetable garden, Tomato, and Hose.
- Complete or reuse a three-trial bucket-and-stopwatch hose-flow measurement.
- Enter ZIP code
92243, which is resolved locally to CIMIS ETo Zone 18. - Use the approximate four-square-foot root area of one tomato plant and add basic soil context.
- Report recent watering and rain.
- Receive the primary recommendation: Water 4 days this week — About 49 seconds each day with the saved field-test hose measurement.
The recommendation screen gives the action first. An optional explanation preserves the ZIP-to-zone match, historical April CIMIS ETo, reviewed UC 21427 tomato crop coefficient, watered area, measured hose flow, recent conditions, confidence, limitations, and source provenance.
The demo is deliberately narrow. Tomato is the only connected plant and hose is the only connected delivery method. Other visible choices return corrective guidance instead of fabricated watering advice. Historical monthly ETo is labeled as historical rather than current weather. The four-day schedule used by the deadline path is visibly identified as a behavioral test fixture and lowers confidence; plant demand, gallons, and measured hose duration are calculated deterministically rather than hard-coded.
How I built it
What existed before Build Week
Before Build Week, I had gathered substantial irrigation-domain research, source documents, provider evaluations, product requirements, possible architectures, and UI explorations. Some of those documents were created in earlier AI-assisted planning sessions so that later work would not depend on a single long conversation.
They were not an implementation. There was no completed iOS product or production recommendation engine. During Build Week we made this distinction explicit in the repository: research means investigated, proposed means intended but unapproved, accepted means an approved direction that may still be unbuilt, and implemented means present in code or packaged data and verified by tests or builds.
What I built during Build Week
I used Codex in the ChatGPT desktop app to coordinate the local repository, GitHub pull requests, Xcode, the iOS Simulator, and the review-and-approval workflow. GPT-5.6 inside Codex served as the implementation partner. I provided the irrigation-domain judgment, source knowledge, product principles, field observations, corrections, and approvals; GPT-5.6 translated those decisions into reviewable documentation, SwiftUI, domain code, local data, persistence, migrations, provenance, failure handling, and tests.
The resulting Swift implementation separates the homeowner interface from a provider-neutral deterministic recommendation layer. The current path chains:
ZIP -> CIMIS ETo zone -> historical ETo -> UC tomato crop coefficient -> crop-water depth -> watered area -> gallons -> measured hose flow -> hose duration -> recent-condition override -> homeowner action
Validated static data and calculations remain local. The app does not require an account, backend, API key, Homebrew, or runtime network connection. This was an intentional architecture decision: future providers may improve freshness or coverage, but they should not own the scientific engine.
The engine also preserves an inspectable calculation trace. It distinguishes historical, published, derived, user-reported, measured, missing, and unsupported inputs rather than flattening them into an unexplained answer. Scientific source precedence and missing-data behavior are recorded in accepted architecture decisions.
I implemented the project through small GitHub increments: first the Xcode/GitHub/Codex workflow, then the rebuilt homeowner experience, measured hose flow and persistence, source and coefficient verification, the canonical recommendation engine, and finally the connected per-plant tomato result.
Challenges I ran into
Making a simple answer scientifically honest
The hardest product problem was deciding what not to claim. Historical ETo is not current weather. ZIP and ETo-zone boundaries can conflict. A plant factor is not the same thing as an edible-crop coefficient. Soil type does not invent a universal time to runoff. Missing evidence must produce a corrective question or reduced confidence, not confident-looking precision.
Turning controller formulas into hand-watering guidance
QWEL scheduling guidance is designed around irrigation systems. A homeowner's hose has a measured gallons-per-minute rate, and a phone can time seconds. Blindly applying controller whole-minute rounding could substantially overapply water. We recorded and tested an explicit measured-hose adaptation that preserves the calculated volume and retains cycle-and-soak behavior only when the required evidence exists.
Field testing exposed trust failures
My first real one-gallon hose test revealed that the calculated result was not visibly restored after navigation, making saved data appear lost. We repaired the persistence behavior for one-, two-, and five-gallon containers and kept a previous valid result during an incomplete retest.
Later product testing exposed two more problems. A 100-square-foot tomato patch produced a mathematically valid but absurd homeowner task, so we reframed the demo around one tomato plant and a four-square-foot root area. The first compact result then looked like one 49-second watering instead of four watering days, so watering frequency became part of the primary recommendation.
These were not cosmetic changes. They were examples of product judgment correcting technically valid but practically misleading output.
Accomplishments that I'm proud of
- A working SwiftUI experience designed for a homeowner holding a hose in one hand and a phone in the other.
- A field-tested three-trial hose measurement that persists across navigation and relaunch.
- A deterministic, provider-neutral engine that keeps formulas out of the main experience while retaining provenance and intermediate calculations.
- A local ZIP-to-CIMIS-zone lookup, packaged historical ETo, and one exact reviewed UC tomato coefficient connected to the app.
- Honest unsupported and missing-evidence behavior rather than invented scientific values.
- Twenty-nine deterministic tests covering calculation accuracy, source integrity, crop-coefficient provenance, hose measurement and persistence, observation overrides, error behavior, and repeatability.
- A successful Xcode iOS Simulator build and product validation of the complete homeowner path.
- A repository history that preserves product decisions, corrections, and implementation state rather than presenting planning documents as finished code.
What I learned
The simplest homeowner recommendation can require the most disciplined engineering. Complexity has not disappeared because the interface contains one sentence; it has been resolved into a sentence.
Real-world testing was indispensable. Unit tests could verify that flow-rate math and persistence encoded correctly, but standing in the garden revealed whether the app felt trustworthy and whether its recommendation was something a person would actually perform.
I also learned that effective AI-assisted development requires a strong human product and evidence boundary. Codex and GPT-5.6 could move quickly across research, code, tests, Xcode, and GitHub, but speed was useful only when each increment had explicit scope, source authority, acceptance tests, and human review. The most valuable collaboration was iterative: build, inspect, test in the real world, correct, and preserve the decision.
What's next for WhenToWater?
The next step is not indiscriminate feature expansion. It is replacing the deadline scheduling fixture with accepted homeowner observations and extending the same evidence contract carefully.
Planned serious-alpha work includes reviewed WUCOLS landscape records and UC vegetable and fruit crop coefficients, crop growth stage, additional California ZIP and CIMIS zones, current CIMIS and rainfall as optional freshness providers, watering-can and pitcher quantities, measured drip and spray application paths, soil-informed cycle-and-soak guidance, and saved hydrozones.
The architecture remains California-first and local-first. Static scientific data, calculations, measured delivery, saved watering information, and provenance should stay on the phone wherever practical. Network services should improve freshness and coverage without taking ownership of the recommendation logic.
The commercial goal is a trustworthy everyday service that helps homeowners apply the water their plants actually need—without requiring them to become irrigation experts. Saving water - and money, on wasted water.
Log in or sign up for Devpost to join the conversation.