I did not start building BrokenBooks because I wanted to build software.
I started building it because the same accounting workflow problem kept showing up in different forms.
I would review a QuickBooks Online file, document what I found, ask the client questions, evaluate the answers, decide what the evidence supported, define the work, price the engagement, perform the cleanup, and eventually hand the books forward.
And somewhere between each of those stages, I kept rebuilding context I had already created.
The work was not disappearing. The understanding was.
A client had already answered the question, but the answer was buried in an email thread.
I had already investigated the balance, but the reasoning lived in notes that were useful to me and much less useful to the next person.
A finding had already been established, but the proposal still required me to explain the problem again. The cleanup plan required another translation. The next reviewer needed another explanation. The CPA needed the history again at year-end.
The information existed. The system around the engagement was not preserving it.
That was the real problem I wanted to solve.
My own accounting background is heavily rooted in cleanup, reconstruction, systems, and the kind of files where the visible problem is rarely the whole problem. But BrokenBooks is not being built only for files at the far end of the complexity spectrum.
Bookkeepers and accountants review QuickBooks Online files for a lot of reasons. Sometimes it is an initial assessment. Sometimes it is a comprehensive diagnostic. Sometimes it is cleanup planning, onboarding, quality control, review before tax preparation, or financial due diligence.
The depth changes. The need for a structured review does not.
I wanted the system to preserve the reasoning, not make the judgment.
That distinction has shaped BrokenBooks from the beginning.
The software can give the review structure. It can preserve findings, evidence, client context, unresolved questions, and the work those findings create.
But the professional still has to decide what the evidence means.
I do not want software pretending that every accounting question has an automatic answer. I want a system that makes it easier for a bookkeeper or accountant to show what was reviewed, what is supported, what is still unknown, and what should happen next.
BrokenBooks grew from that gap.
The diagnostic became the foundation because that is where the accounting understanding is created.
From there, the bigger question became: how much of that understanding can remain useful as the engagement moves forward?
That question is what pushed BrokenBooks beyond a diagnostic tool and into a broader engagement system.
I am building it from inside the work itself, and this blog is where I will share that journey: the problems, the philosophy, the decisions, the lessons, and the parts of building accounting software that surprised me.
I will share the thinking. I will not publish the internal machinery that makes the product work.
That feels like the right balance.
