ZESA / Water / Daily Life — PARKED¶
Original idea: Live load-shedding schedule per suburb with push alerts, water/borehole tracking, gas refill locations.
Rank: 5 of 5. Score: 4.80.
Verdict: Do not build. The premise has expired.
Reopen if: scheduled load-shedding returns for 60+ consecutive days.
1. Why this was the best idea in the set — and why it isn't anymore¶
In 2023 this was the strongest concept on the list. Every part of the reasoning was correct: everyone checked the schedule three times a day, the pain was universal, the urgency was high, and an app that told you "power going off in 30 minutes" had obvious daily value.
Then the problem went away.
The evidence¶
| Date | Fact | Source |
|---|---|---|
| May 2026 | ZESA claims 138 consecutive days without load-shedding; US$210M Afreximbank facility; active SAP market trading | Energy News Africa |
| October 2026 | ZESA claims 304 consecutive days without scheduled cuts; needs 61 more days for a full year (~27 Dec 2026) | ZESA via Pindula / The Herald |
| October 2026 | Government says Zimbabwe is exporting power surplus to the regional grid | Pindula |
| Target | End load-shedding by Dec 2026; end power imports by 2027; full electrification by 2030 | ZESA Group CEO |
An app whose core value proposition is "power going off in 30 minutes" cannot be sold in a market that has not had a scheduled cut in ten months.
2. The compounding problem: the incumbent owns the data¶
Even if load-shedding returned tomorrow, the entry is much harder than it was:
| Competitor | What they have |
|---|---|
| ZETDC official app | On Google Play. The utility's own data. Authoritative by definition. |
| ZESA Self Service Portal | Bill payment, usage, fault reporting — a broader relationship than an app |
| poweroutage.live | Harare outage schedules, already operating |
| Propzone / news outlets | Publishing suburb-level supply analysis as content |
We would be a less-informed copy of the entity that controls the data. There is no path to being better — only to being second.
3. Why the water half doesn't rescue it¶
The natural response is: "keep the water and borehole tracking, drop the electricity."
| Consideration | Assessment |
|---|---|
| Is the pain real? | Yes. Harare's water supply and rationing remain a genuine daily problem. |
| Is the data available? | No central authoritative source comparable to a utility schedule. Council schedules are inconsistent and often unpublished. |
| Can it be built? | Only by crowdsourcing — residents reporting pressure, borehole levels, bowser locations. |
| Does crowdsourcing work cold? | No. A water-status map is worthless until it has dense neighbourhood coverage, and it has no coverage until it has users. Classic cold start. |
| Does anyone pay? | Borehole drillers and water bowser operators would pay for leads. That's a real but small market. |
| Is it one product or two? | It's a different product with a different data model, different users, and different monetisation. Bolting it onto a dead electricity app doesn't create a business. |
Verdict on the water pivot: it is a legitimate but small idea with a structural cold-start problem and weak monetisation. It does not merit the effort when Car Care scores 7.80.
4. What would change the verdict¶
| Trigger | Threshold | What we'd do |
|---|---|---|
| Load-shedding returns | 60+ consecutive days of scheduled cuts | Reopen. But even then, the ceiling is an ad-supported utility app, not a company. Consider it only as a feature inside a broader daily-life product. |
| ZETDC app is withdrawn or abandoned | Confirmed unmaintained for 6+ months | Removes the incumbent advantage, but not the "no revenue model" problem |
| A municipal water API is published | Any authoritative real-time source | Makes the water product buildable without crowdsourcing cold start |
| A large utility partnership is offered | A funded contract | Changes it from a startup to a contract — a different business |
Note the shape of these triggers: none of them are things we can cause. That is itself a signal. A business that only becomes viable when an external event happens is not a plan, it is a lottery ticket.
5. The transferable lesson¶
This idea wasn't wrong — it was time-bound. It was correct about a problem that existed and then stopped existing.
Two lessons worth carrying:
- A pain-based thesis has an expiry date. "People check this three times a day" is a description of a moment, not a structural fact. Every problem definition in this repo should state what would make the problem disappear, and whether that's likely.
- The best market is one where the pain is enforced by a third party. Load-shedding was enforced by ZESA's generation capacity — which improved. A car's service interval is enforced by physics — which does not improve. Car Care's pain cannot be solved by a policy announcement.
That second point is the real reason Car Care outranks this idea, and it's a durable advantage, not a timing one.
6. What we'd build if forced to build this¶
Recorded for completeness in case the revival trigger fires.
Minimum viable: a suburb-level outage feed with push alerts, aggregating from ZETDC's published schedule plus user reports of actual outages.
The one differentiator worth attempting: actual vs scheduled. The utility publishes what should happen; nobody reports what did. "Scheduled: off 08:00–14:00. Actual: on at 11:40." That gap is where the real information is, and it's crowdsourceable at low density because it only needs one report per feeder, not per household.
Revenue: local advertising (US$50–100/month per advertiser) and nothing else. No consumer payment, no B2B lead value worth mentioning.
Expected outcome: a well-liked free app with US$200–500/month in ad revenue and a support burden that exceeds its value. Which is why it's parked.