There's a story making the rounds that every solo builder will recognize. Someone scratched their own itch: a small tool for splitting the bill when a group travels together. Everyone logs expenses, each entry lets you pick who it's shared among, and at the end you press one button to get the cleanest set of who-pays-whom transfers. After settlement, the records lock so nobody can quietly rewrite history. The developer shipped it, posted about it, got a lukewarm response (plenty of people called it a fake need), and then basically walked away.
Months later a user pinged them to say the thing was down. The server process had been killed under load. When they looked at the backend, they found something they hadn't expected: real usage, and more than 900 groups of expense data sitting in the database. That was enough of a nudge to add auto-restart, cross the threshold for the platform's ad program, and switch on two ads. The reported take is around 10 yuan a day, enough that a year of it might cover the server bill. Modest numbers, but real ones.
The part worth keeping vs. the part that keeps breaking
What's interesting here isn't the revenue. It's the split between the fragile part and the durable part of this product.
The fragile part is the always-on server. A process that gets killed under pressure, needs babysitting, needs auto-restart glued on after the fact, and quietly becomes a liability the moment the tool succeeds. For a project the builder honestly describes as something they stopped maintaining, that's a lot of operational surface area to keep alive just so a settlement calculation can run.
The durable part is the logic and the data. Three things are doing the real work:
- the minimal-transfer algorithm that turns a messy pile of shared expenses into the fewest transfers that settle everyone up
- the per-entry split shares, so each expense knows exactly who it was divided among
- the locked-after-settlement records, so once a trip is closed the ledger can be read and audited but not edited
None of that needs a heavyweight, hand-managed server. It needs somewhere to run a bit of Python and somewhere trustworthy to store rows. That's the reframe worth stealing.
What a rebuild looks like on hosted pieces
If I were rebuilding the durable half without owning a box that can get OOM-killed, I'd split it into three concerns and map each to a hosted piece.
First, the math. The settlement algorithm is pure computation: take the net balance for each person across all entries, then greedily match the biggest creditor to the biggest debtor until everyone nets to zero. That's the classic minimal-transfer reduction, and it's a natural fit to run Python online as a small function rather than a daemon you have to keep breathing. You call it when a group closes a trip, it returns the transfer list, and there's nothing sitting idle waiting to be killed.
Second, the data. An expense ledger is a textbook relational shape: a groups table, an entries table with amount and payer, and a join table for the split shares on each entry. SQLite handles this comfortably at the scale described (hundreds of groups is nowhere near a stress point), and being able to open a SQLite editor to inspect rows, fix a bad entry during development, or eyeball the schema beats guessing at what the backend actually stored. The immutability requirement maps cleanly too: model settlement as a state flag on the group, and have the write path refuse edits to any entry whose group is already settled. The lock lives in application logic over a durable file, not in a running process's memory.
Third, the interface. The screens people actually touch, logging an expense, picking who shares it, viewing the final transfer plan, are HTML. Putting them on web app hosting means the front end is served without you standing up and guarding a server. The Python execution and the SQLite file behind it do the stateful work; the HTML is just the surface.
Where the boundary is honest
I want to be straight about what does not move over. The original product is a WeChat mini-program, and its money comes from WeChat's traffic-master ad program. That shell and that monetization path live inside WeChat's ecosystem, which is outside what these hosted capabilities cover. So a VicroCode rebuild reconstructs the engine and the records, the part that was durable all along, not the mini-program container or the ad integration. If your distribution and revenue are tied to that channel, treat this as rebuilding the reliable core, then keep the channel wherever it already works.
A second honest note: any figures here (900+ groups, ~10 yuan a day, covering server costs over a year) are the original poster's self-reported numbers. I haven't independently verified them, and I'd treat any claim about performance or reliability of a rebuild as unverified until you've actually run it under real load.
The wider signal for small builders
Zoom out and the same pattern shows up across a lot of solo-project experience. One builder's write-up put it well: AI mostly lowers the cost of trying things, but writing code fast doesn't mean the need is right. Ship one small annoyance end to end, get a few people to actually use it, and only add more when they come back. The expense-splitter is exactly that shape, a specific recurring annoyance, not a platform.
The trap that follows a small win is operational. The moment a tool gets used, the always-on server becomes the thing most likely to page you at a bad time. Separating the durable logic and data from the fragile hosting is what lets a side project survive its own modest success without turning into a second job. Keep the algorithm, keep the ledger, keep the lock. Let the process-that-can-be-killed stop being the single point of failure.
That's the reproducible takeaway. Find the small annoyance, isolate the part that's genuinely durable (usually a bit of math plus some rows that must not change), and host those pieces so they don't depend on you keeping a server alive by hand.