Case study · Built by our founder
Alight Electricity
A mobile app for residents of a Nepali municipality: log in, pull up past and current electricity bills, see an estimate of what the month will cost, and pay online through the e-Seva gateway instead of paying in cash in person.
The story
Alight Electricity predates Inseed. Our founder built it as the sole mobile engineer, one of his earliest shipped products, on a project for a Nepali municipality whose electricity billing was still fully cash-based. It is founder-portfolio work, not an Inseed client project, and it is the govtech and payments story the team leans on.
Every month, residents had to pay their electricity bill in person, in cash. There was no way to check what you owed, look back at old bills, or settle up without physically showing up. The brief was to digitalize the whole thing: put the bills in people’s hands and let them pay from a phone.
The catch is that a utility bill is not a casual transaction. If the app says a bill is paid, it has to actually be paid, and the billing records behind it have to agree. So the real work was less about screens and more about making an online payment reconcile cleanly against the municipality’s records.
What we built
The app shipped on iOS and Android from a single React Native codebase. Residents log in with their customer ID or phone number, with phone login verified over OTP, and land on their bills: the current month plus history they can pull up on demand.
On top of the raw bills, the app adds a forward estimate of what the current month is likely to cost, based on the customer’s billing cycle, plus a set of electricity-saving tips so the number is not just a figure but something a resident can act on.
Paying is the core loop. Tapping Pay hands the resident off to the e-Seva merchant flow, where they authorize with their own e-Seva credentials. The amount is deducted, the result is written back to the billing database, and the bill is marked paid. Our founder owned the entire mobile surface end to end, from the app itself through the client-side payment integration and the full App Store and Play Store submission, while a separate engineer owned the existing backend and APIs.
Architecture
The mobile app is React Native across iOS and Android. The billing data and APIs already existed, owned by a separate backend engineer and backed by MySQL, so the mobile side was deliberately a thin, reliable client over that system rather than a place to re-implement business logic.
The load-bearing piece is the payment path. Paying a bill is an OAuth-style redirect: the app sends the resident into the e-Seva gateway to authorize with their own credentials, e-Seva deducts the amount, and the outcome is reconciled back into the billing database so the bill flips to paid. The diagram below traces that flow, from login through bill lookup to the e-Seva redirect and the write-back that keeps the app and the billing records in agreement.
Selected screens
Stack
One decision worth telling
The hard part of the payment feature was never the redirect into e-Seva; it was what happened after. Money moves in one system and the bill lives in another, and if those two ever disagree, a resident who paid still looks like they owe.
So the integration was built around reconciliation, not just checkout. After e-Seva authorizes and deducts, the result is written back to the billing database and the bill is marked paid, so the app’s state and the municipality’s records settle to the same answer. On a utility bill, that agreement is the whole product.
Outcome
What we would do differently
Most agencies skip this section. We include it because honest hindsight is the kind of credibility you cannot buy.
Reconciliation leaned on the flow coming back cleanly from e-Seva. Today we would confirm the payment through a server-side callback or webhook with idempotency keys, so a bill is marked paid on a trusted signal from the gateway rather than on the client completing its redirect.
The next-cycle estimate was derived from the billing cycle, which was enough to be useful. Making the estimation an explicit, testable model, tied to actual usage rather than cycle timing alone, would make the number more accurate and easier to reason about.
As an early project it did more coordination on the device than it needed to. Keeping the mobile app a thin view over the billing system, with payment state settled entirely server-side, would leave fewer ways for the app and the records to drift apart.
Related work
Built by Inseed
Zero to App Store in under 4 months. Past 3,000 users in the next 3.
Read the case studyBuilt by Inseed
Vibe search shipped in 3 weeks. AI searches up ~200%.
Read the case studyPayment gateways, billing reconciliation, government and utility workflows. Tell us what you are shipping and we will tell you what the first four weeks can de-risk.
Book your audit