They were reconciling payments with a printout and a pen

A pharma wholesaler I work with used to reconcile incoming payments like this: print the bank statement, go down the page with a pen, and write next to each line which bill it was for.

Every payment. By hand. Every time.

It worked, in the sense that the business ran. It just consumed hours of somebody's week doing something a computer is better at, and it produced no record you could query afterwards. Once the printout went in a drawer, the knowledge in those pen marks was gone.

Why the pen marks mattered

The instinct is to look at that and think "spreadsheet." I would have got it wrong that way.

What the pen was actually doing was matching: taking a line on a bank statement, which is a dense and inconsistent string, and deciding which customer and which bill it belonged to. That is the whole problem. Everything else, the totals and the reports and the outstanding balances, falls out of it once the matching exists.

Watching someone do it by hand is what makes that obvious. The pen marks were the requirements document.

Why it runs on their machine

This is the decision that shaped everything else, and it was not mine.

The data is money. Every row is a real payment from a real customer. The business wanted that staying on a machine they own, not sitting on someone else's server, and once you accept that, a desktop app stops being an odd choice and becomes the obvious one.

Local-first bought a few things at once:

• No accounts, no logins, no password resets. The app opens and it works. For a non-technical user this is not a small feature.
• No server to run. Nothing to keep alive, patch, or bill anyone for.
• The privacy guarantee is structural. Not a policy in a document, but a property of where the software runs. Nothing is uploaded because there is nowhere to upload it to.

SQLite on their disk, and that is the whole storage story.

The unglamorous part is the product

Every Indian bank exports statements differently. Different column orders, different date formats, Excel serial dates, amounts with currency symbols, amounts in accounting parentheses, trailing CR and DR flags, debit and credit split across two columns or signed in one. Then the description strings themselves: UPI, NEFT, IMPS, RTGS and cheque references, each with their own shape, plus the wallets.

People ask which format was the worst. Honestly, none of them. There was no clever trick and no single monster to defeat. They are just all different, so you read each one, work out its layout, and write the parser for it. Then you do that again for the next bank.

The app detects which bank a file came from and runs the matching parser. That detection plus the pile of format handlers is most of the code, and it is the least interesting code to write and the most important code in the product. If it does not handle the bank this particular business actually uses, nothing else about the app matters.

I think this is a generally underrated shape of work. The hard part is rarely the algorithm. It is usually the fifty specific real-world cases that stand between a demo and something a business can rely on, and there is no way to be clever past them.

Where it goes next

The same business is now the pilot for Pharmulo, the ordering platform I am building over their existing ERP. Reconciliation belongs in that story, so the plan is to fold this in rather than leave it as a separate app on one machine.

Which is a slightly funny ending: the local-first decision was right for the problem as it existed, and the thing that changes it is not a technical argument but the business growing into a different shape. That happens more often than tooling debates admit.