The easier version of a client-facing financial product is a dashboard: pull numbers from somewhere else, present them well, ship fast. It photographs well in a demo. The harder version is to be the actual system of record — the place where the numbers live, not just where they're displayed. The decision made here was the harder version, and the reasoning behind it is more interesting than the choice itself.
The competitive scan that settled it
Before committing, the field got scanned: eight comparable products, none of them actually doing real accounting underneath their reporting layer. That mattered more than any single feature comparison, because it meant the entire category was competing on presentation of numbers that ultimately lived somewhere else — which means none of them had built the thing that's hard to leave. A user can export a dashboard's view and switch products in an afternoon. A user cannot export their books that easily once those books are the real ledger, not a read of someone else's.
The moat isn't the feature list. It's whatever makes leaving expensive. A dashboard on top of someone else's data has none of that. Real, structured books do.
Why the hardest integration went last, not first
The obvious sequencing for a project like this is to connect the bank feed early — it's the flashiest, most "automatic" part, and it's what most competing products lead with. Here it was planned for last. The reasoning: bank-feed integration is also the single riskiest place to get the books wrong, because a bad automated categorization silently corrupts the ledger it's supposed to be feeding. Building the manual, structured parts of the system first — and getting those provably correct — means the automation layer has something solid to plug into, instead of being the foundation the whole system depends on getting right on day one.
The tradeoff
Real books are slower to ship and far less demoable early — there's no flashy "connect your bank and watch it populate" moment in the first several milestones. That's a real cost against a competitive field that leads with exactly that moment. It's accepted because the alternative risk is worse: wrong books are worse than no books at all, and a system that looks impressive but silently miscategorizes transactions is a liability wearing a feature's clothes.
What would change the answer
If the product's users mainly wanted a quick read of numbers they already trust from elsewhere — a glance, not a record — a dashboard would be the right call, and building real books would be over-engineering a viewer. The decision only holds because the target user needed the numbers to *be* the record, not just describe one that lives somewhere else.