Noku is a dual-interface app: a mobile app for residents and a responsive web dashboard for the committee. I designed it for the mini-estate I used to live in, after talking to residents across three estates, then checked the core ideas with the same residents. The resident app is built in Next.js.

How a flat bill turned into a trust problem

In the estate where I used to live, residents were paying the same generator bill, even though their households used different amounts of power.

The mini-estate I lived in has 24 units across four buildings, with one generator managed by an elected committee. Everyone pays the same flat annual levy regardless of how much power they consume, and the levy is collected together with other levies into the estate's general account. When the fund ran short, the committee asked everyone to pay more, and some residents refused because they couldn't see where the money had gone.

In March 2026, economic effects from the crisis at the Strait of Hormuz caused a roughly 50% spike in the cost of power (fuel and other energy sources) in Nigeria. The money residents had all paid upfront could no longer cover the year. The committee requested an emergency top-up, and many residents refused, certain the funds had been mismanaged.

Generator hours were rationed, and residents who had paid in full ended up receiving less power than they were owed. Some responded by running more appliances during the limited generator windows, trying to extract value, which burned fuel even faster.

I spoke with six residents across three estates, and their concerns were the same: how bills were worked out, where the money went, and what happened when the fund ran low. I designed a resident app and a committee dashboard around those issues, then checked the core ideas with the same residents.

What I found across three estates

To understand whether this was a local frustration or a structural pattern, I spoke with residents across three different estates.

Every estate had the same core friction: equal billing regardless of consumption, no or little transparency as to how funds were spent, and recurring tension whenever the committee needed more money. However, three differences surfaced that pointed toward possible solutions.

Estates that kept generator funds in a dedicated account had significantly less suspicion around spending.

One estate collected payments monthly and absorbed fuel price swings without emergency levies.

The estate that had individual unit meters experienced the least billing conflict, but this was the exception; most estates had no metering infrastructure.

These points shaped my design direction, to build a tool not to control the generator, but one that makes the flow of money, billing, and power management transparent to everyone who depends on it.

The product

Noku is a dual-interface app: a mobile app for residents and a responsive web dashboard for the committee.

Residents get a mobile app for checking power status, seeing what they owe and why, and paying their contributions. The committee gets a web dashboard for tracking payments, logging fuel purchases, and projecting when the fund will run out.

Four design decisions defined the product:

1. Formula-based proportional billing

The biggest source of resentment is that a household of six running an AC pays the same as a single person who is barely home. But without physical meters on every unit, which requires hardware investment most estates have not made, you cannot measure actual consumption.

I designed a formula using three inputs already known to the estate and difficult to game: number of occupants, number of bedrooms, and number of AC units. A weighted formula calculates each unit's percentage share of total fuel costs. No self-reporting, which may lead to residents gaming the system. No committee-assigned tiers (light, medium, and heavy), which puts the committee in the position of judging their neighbours and leads to social tension. The formula is visible in the app so residents understand exactly why their bill is what it is.

2. Monthly prepaid billing with retroactive adjustment

My research showed that monthly collection absorbs fuel price volatility naturally, eliminating emergency mid-year levies that erode trust. Residents pay an estimated amount at the start of each month. For the first three months, the committee sets this estimate manually, which mirrors what they already do. After three months, the app calculates estimates automatically from historical fuel data, gradually shifting billing from a human judgment call to a data-driven output.

3. Framing overdue payments by impact instead of blame

When the fund is underfunded, the resident app shows "18 of 30 generator days covered this month" rather than naming or counting non-payers. In a 24-unit estate where almost everyone knows their neighbours, even an anonymised count is not truly anonymous. Showing the fund impact communicates urgency without creating shame or interpersonal conflict.

The committee retains full visibility into individual payment status on their dashboard, with tools to send private reminders and log external payments. Accountability is structural (automated tracking, persistent records) rather than social (public naming). I deliberately kept enforcement actions like power cutoffs (where the committee shuts off power to defaulting residents) outside the app entirely.

4. A way to report issues and see them acted on

Two residents I interviewed wanted a better way to lay complaints, and a record showing those issues had been acted on. I designed a reporting flow in the resident app to give them both.

Residents choose from five categories (billing, household data, generator, payment and other), each with an example so they can tell which one fits. They then add a subject and a description, and can attach a file. The estate admin handles each report, and every report carries a status, such as In review or Resolved, that residents can follow from the Reported Issues list in their profile.

What changed after I checked back

I returned to several of the residents I had initially interviewed and walked them through the core concepts: monthly billing, the formula, the fund-health display and the reporting flow.

The formula was accepted, but only if it remained visible. One person said, "If I can see how the number is calculated, I can argue with the formula." That shaped the final bill design: the formula breakdown is now front and centre on all payment screens.

Monthly collection was also welcomed, though one resident said they preferred annual payments out of habit.

What's next

Try the resident prototype

Resident mobile PWA (invite code: 123456). Admin web app: coming soon.