Irrigation District Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the register get modelled as one turnout to one parcel?

It is the shape a developer draws on the whiteboard in the first meeting, because it is the shape the words suggest. A grower has a parcel, the parcel has a turnout, the turnout delivers water, the account gets billed. Every district map contradicts it within about four minutes.

One parcel is served by two turnouts because a lateral was extended after a purchase. One turnout serves three parcels under two owners because a family split the ground and never asked the district to change anything. A parcel was subdivided and the assessor created four new parcel numbers while the district register still carries the original. A water right attaches to acreage that does not match the modern parcel boundary at all. None of these are exotic, and all of them break a one to one model.

The consequence is not cosmetic. Assessments attach to parcels rather than to customers and follow the land through sale, so a register that cannot express the real relationships produces bills that go to the wrong person, allotment balances that cannot be transferred correctly, and delivery records that cannot be attributed when a grower disputes one.

Specify the register as a many to many model from the start, with turnout, parcel, water right and account as separate entities and explicit relationships between them, each carrying validity dates so a change in 2026 does not silently rewrite how 2024 would be calculated. Then test the model before you commit: hand the developer three genuinely awkward cases from your own maps, including a shared turnout and a split parcel, and ask them to draw the records. That exercise costs an hour and it predicts the whole project.

What goes wrong when you migrate parcel and account history?

Parcel data is the single most common source of schedule overrun in this category, and it is not the developer's work. It is yours.

Reconciling a district turnout and account register against a county assessor roll surfaces decades of splits, mergers and corrections that were never propagated. Accounts exist for parcels that no longer carry that number. Two accounts point at the same ground. An owner of record died and the account still carries their name. Acreage in the district register disagrees with assessed acreage, sometimes by enough to change a per acre assessment materially.

Software cannot resolve any of that, because each item needs a decision from someone who knows the district. What it can do is surface exceptions in a reviewable queue and preserve the original record alongside the corrected one.

Handle it as its own workstream, staffed with district personnel, started before development rather than during it. Take one lateral or one division first and reconcile it fully, which both proves the process and gives you a realistic multiplier for the rest. Any developer who does not raise parcel reconciliation in the first conversation has not built for a district, and their schedule will be wrong by the size of the work they did not mention.

Why do telemetry and county roll feeds break after launch?

Districts run mixed measurement estate: telemetered sites of more than one brand and vintage, staff gauge and flume readings taken by hand, and rider estimates where there is nothing else. The integration failures cluster in predictable places.

A site loses power or a radio link and reports its last value indefinitely, which looks like steady flow rather than an outage. A replaced device reports in different units or under a different tag name. Daylight saving shifts an hour of flow into the wrong day. A recalibration goes unrecorded, so a step change in readings looks like a change in demand.

The county roll feed fails differently. It arrives annually or on a schedule the county sets, the format changes when the county changes systems, and new parcel numbers appear that your register has never seen. Import it without validation and your assessment roll quietly diverges from the county's.

Build both with the same discipline: validate the shape on arrival, quarantine what does not match, and run a completeness check that reports which sites did not deliver data yesterday. The most valuable single feature here is a stuck value detector, because a frozen reading is the failure a district discovers three weeks later when a grower disputes a bill.

What happens when carryover, transfers and shortage proration are not covered?

Districts that administer a straightforward duty per acre with no carryover can survive on simple arithmetic. The moment your rules include carryover from one season, transfers between parcels or accounts, or proration in a shortage year, manual administration starts producing different outcomes for different accounts in the same year, and that inconsistency is what turns into a board complaint.

The specific gaps are worth naming. Carryover needs a rule about what may be carried, how much, whether it expires, and whether it is subordinate to fresh allotment in a shortage. A transfer needs an effective date, an approval, and an effect on both the sending and receiving balance that cannot be applied twice. Shortage proration needs to be applied to every account at once by the system rather than account by account by a clerk, because a partial application is worse than none.

The compliance dimension is the audit trail. Delivery and assessment history is evidence in a water rights dispute and in an enforcement action, and it needs to survive one. That means an append only record where corrections are recorded as attributed corrections rather than as edits, and where the apportionment rule used at a shared measurement point is stored with the delivery rather than recalculated later by whoever is asked. There is no perfect answer to shared measurement. There is a recorded, repeatable, board approved rule, and there is guesswork, and only one of them is defensible at a hearing.

Should you build custom or configure what you already own?

Do not build if you are a small district under roughly 150 turnouts on a single canal with flat per acre assessments, no allotment carryover and no transfer market. A spreadsheet, a scheduling book and an experienced clerk are honestly sufficient, and the money is better spent on structure maintenance and measurement.

Be equally clear about what canal automation does and does not solve. Rubicon Water is good at what it is for: gate control, flow measurement and the operational software around modernised infrastructure. If your problem is that manual gates deliver imprecise flows and the canal loses water to poor control, that is the right investment and no administration system substitutes for it. What it does not give you is an allotment ledger in acre feet per parcel with carryover and transfers, an assessment roll that reconciles to the county assessor, a delinquency process, or an audit trail built for a hearing where a landowner has counsel. Districts that modernise the canal and continue to administer water on paper have improved the measurement and left the disputes exactly where they were.

Build when two or more of these are true: your allotment rules include carryover, transfers or shortage proration; your assessment roll no longer reconciles cleanly to the county; a delivery dispute has reached your board or your counsel; you have modernised measurement and are still administering on paper; or your longest serving ditch rider is close to retiring and a meaningful part of the district's operating knowledge is going with him.

How do hidden costs get into a district software quote?

• Parcel reconciliation. The largest and most consistently omitted item. It is your staff's time as much as the developer's, and it happens before value is visible.
• Mixed telemetry brands. Each device family is its own ingestion and validation problem, and older units are harder than new ones.
• Allotment rule complexity. Carryover, transfers and class based priorities make a genuinely intricate ledger. Describe your rules in writing before asking for a number.
• County roll production. Where assessments are collected on the tax roll, the system must produce and reconcile that file in the county's format, not merely print invoices.
• Offline field capture. Conflict handling when two riders sync overlapping work is real engineering, and it roughly doubles field application cost compared with a web form.

For orientation, Digital Heroes delivery experience puts a first release covering the turnout, parcel and account register, water ordering against canal capacity and ditch rider delivery capture at $60,000 to $130,000 over 12 to 16 weeks, with a full platform at $150,000 to $350,000 across 6 to 11 months.

What separates a build that works from one that fails here?

Whether the ditch rider will actually use it. The field application has to work with no signal, in direct sunlight, one handed, from a truck, by someone wearing gloves. Gate settings, times, readings, adjustments and notes are captured on the canal bank and synced later without creating duplicate deliveries. If the proposal is a responsive web page, the person proposing it has not spent a morning riding a lateral, and the riders will keep the paper card alongside the tablet, which leaves you with two records that disagree.

Whether water ordering knows about capacity. An order accepted without checking the reach it has to travel through is a scheduling promise the canal cannot keep, and the person who discovers that is the rider at seven in the morning. Orders should be checked against reach capacity and the rotation at the moment they are placed, with the operational consequence visible to the office rather than to the field.

Whether the rollout respects the season. Start on one lateral or one division in the off season, keep the existing scheduling book running in parallel for the first weeks of the run so the office has a fallback, and expand once the flow is proven. A district wide cutover in the middle of an irrigation season is the one approach worth refusing outright.

And whether you own it. Get the repository, the cloud accounts and the data in the district's name in writing before kickoff, with the right to hire another firm. At Digital Heroes the client owns the code from the first commit. A district is a public body with a long institutional life and regular staff turnover, and a system your successors cannot maintain or migrate simply recreates the dependency you set out to escape.