I Overengineered a Whole System for Four Electricity Bills
The Hardest Bug Was Never in the Code
THE ASK
My grandmother runs four rental units on one shared electricity meter. Every month, the math is the same: take the LESCO bill, divide by total units consumed, get a rate per unit, multiply that by each tenant's sub-meter reading, write the number on a piece of paper, hand it out.
She has been doing this for years. A calculator, a notebook, and a patience I will never have.
She didn't ask me to build anything. She asked me to help her write four bills one month because her hand was tired.
I heard "four bills" and my brain autocompleted it to distributed billing infrastructure.
THE OVERREACTION
Any reasonable person would have opened a notes app. Typed four numbers. Maybe made a WhatsApp group.
I opened my laptop.
Two days later I had a full-stack web application. A NestJS backend, a Next.js frontend, a PostgreSQL database with billing history going back to whenever I decided to start tracking, and a WhatsApp dispatch pipeline that would automatically send each tenant their invoice the moment I entered the meter readings.
Not just a number. A proper invoice. With a hand-drawn sketch card design. With the tenant's name, house number, consumed units, rate per unit, motor charges, due date, and a little "Digital Khata" watermark at the bottom like this was a Series A startup.
I named it Digital Khata.
I gave it a recycle bin.
A billing system for four tenants, in one house, in one neighborhood, had a recycle bin.
I want you to sit with that for a moment.
ENGAGE / POST REACTIONS
THE RECEIPTS
Let me tell you what Digital Khata actually had by the time I was done.
What It Tracked
Sub-meter profiles for each tenant: name, WhatsApp number, base reading, fixed motor charges, full usage history
LESCO split-rate auto-calculation: scrapes the main bill, figures out the per-unit rate, applies it across all four units automatically
Unit reconciliation with variance gap tracking
What It Did
WhatsApp dispatch pipeline: one button, four tenants, four invoices, zero paper
Two invoice formats: plain text summary and a hand-drawn sketch card with a watermark like we were a registered billing company
Rent collection ledger
Gas bill split engine
A recycle bin. For four tenants.
All of this was built in two days. With AI handling most of the implementation while I directed the architecture. This is the world we live in now. One person, one laptop, two days, and you have something that would have taken a team weeks to ship.
The app worked perfectly.
Nobody used it.
THE FALL
The app was done. Invoices generating. WhatsApp pipeline connected. Session live.
I went to my grandmother and said: this month, I'll send the bills from the app.
She said no.
Not "let me see how it works." Not "show me first." Just no. Paper. Like always.
So I sat down, opened the calculator, and wrote four numbers on four pieces of paper.
The same four numbers the app had already calculated. The same four numbers sitting in a database. The same four numbers with a beautifully rendered hand-drawn invoice attached, ready to send, waiting.
I walked them to the tenants by hand. H-01. H-02. H-03. H-04.
One tenant β just one β I managed to send digitally. A small victory. A proof of concept. A lighthouse in the dark.
The other three got paper.
MONTH TWO: DΓJΓ VU
Month two arrived. I had spent the entire previous month convinced that she just needed to see it work once.
She had seen it work once.
She still said no.
I sat down again. Calculator. Notebook. Four pieces of paper. The app was running on a server in Oracle Cloud, somewhere in a data center, doing absolutely nothing, costing me exactly zero rupees but costing me something else entirely.
One tenant got digital again. The same one. H-01. Muala Dita. Reliable early adopter. Did not ask for this responsibility.
The other three got paper.
I started to wonder if I had built the wrong thing. Then I opened the app, looked at the unit reconciliation screen, watched the variance gap calculate in real time, and thought:
No. The app is fine. The app is perfect. The app is not the problem.
This was the moment I should have reflected deeply on the nature of technology adoption, user trust, and the gap between building something and actually changing someone's behavior.
I did not reflect deeply.
I started adding a gas bill split engine instead.
MONTH THREE: THE BUG WAS NEVER IN THE CODE
Month three. Same setup. Same app. Same server. Same grandmother.
Something was different this time.
I am not going to tell you what changed. I am not going to walk you through the negotiation, the context, the specific sequence of events that led to all four tenants receiving a WhatsApp invoice on the same night for the first time in the app's existence.
Spent three months treating this like a technical problem. Checked the retry queue. Checked the subscription cleanup. Checked the variance gap. Checked everything except the actual root cause, which doesn't have a stack trace and doesn't take a pull request.
Month three, the bills went out.
How β that's between me and my conscience. The ledger doesn't ask follow-up questions, and neither should you.
H-01. SENT β
H-02. SENT β
H-03. SENT β
H-04. SENT β
For the first time in three months, the recycle bin was the least useless part of the system.
THE LESSON
Here is what three months of building a billing system for four electricity bills taught me.
We live in a world where building software is no longer the hard part.
I built a full-stack application in two days. With AI handling the implementation, I was the architect, the product manager, and the only engineer. The barrier to shipping something real, something that works, something with a recycle bin, has never been lower in the history of software.
This is not a flex. This is a warning.
Because if building is easy now, what's left? What's the actual hard problem?
Trust. Habit. Adoption. Change.
My grandmother did not distrust the app. She distrusted the disruption. Forty years of a system that worked: calculator, notebook, paper. It does not get replaced by a WhatsApp message just because the WhatsApp message is objectively better. People do not adopt technology because it is better. They adopt it when the cost of change feels smaller than the cost of staying.
This is true for your grandmother. It is true for your clients. It is true for every company that has ever bought software and never used it.
The graveyard of good software is not filled with buggy code. It is filled with tools that nobody trusted enough to try.
You can build anything now. Seriously, anything. A solo developer with an AI assistant can ship in days what used to take teams months. The bottleneck has moved.
It moved from building to belonging. Your software has to belong in someone's life before they will let it in.
Four electricity bills taught me that.
A recycle bin taught me nothing. But it's there if you need it.
REVIEW / STAR RATING
4.3 / 5 (3 ratings)
FOLLOW / SUBSCRIBE TO FUTURE POSTS
Get email alerts when I publish content on this topic. No spam, ever.