When you build the part of a product that moves money — payroll, finance, approvals — correctness stops being a nice-to-have. The finance module I worked on went through a full revamp, and the reason was instructive: the first version had optimized for the screens, not for the invariants underneath them.
The data model is the product
The rebuild centered on an append-only ledger of transitions rather than mutable balances the app had to keep in sync by hand. Every change to financial state is an entry you can replay and audit, which makes whole classes of drift-and-reconciliation bugs simply impossible to represent.
Approvals are first-class
Approval flows became first-class objects too. Who approved what, when, and what exactly changed should all be reconstructable from the data alone — not inferred from logs or timestamps scattered across tables. In a system people trust with payroll, that auditability is the feature.
Migrations are a ceiling or a floor
The quieter lesson was about migrations. Multi-domain products — finance next to HR next to project management — evolve constantly, and schema you can't change safely becomes a hard ceiling on what the product can become. Investing early in strong, reversible migrations is what keeps that ceiling from arriving.