Financial work is full of terrain changes.
One minute you’re categorizing transactions. The next you’re thinking about estimated taxes. Then you’re reconciling an account, exporting a report, or answering a question from an accountant. The rules are different, the vocabulary is different, and the cost of being wrong is higher than most software acknowledges.
When we say “terrain,” we mean three things:
- The rules are real, and they change.
- People need a map, not a magic trick.
- Every shortcut becomes debt when the stakes go up.
Why “fluent” matters
Fluency is not speed. It’s confidence.
If you’re fluent in a terrain, you can:
- Explain what the system is doing.
- Inspect the assumptions it’s using.
- Recover when reality doesn’t match those assumptions.
That is the bar we set for our products. Not “it worked once,” but “it’s understandable, repeatable, and exportable.”
Why a family of products
Taxes and bookkeeping are tightly connected, but they’re not the same problem.
Trying to jam everything into a single application often creates a UI that’s too heavy, a codebase that’s hard to reason about, and integrations that become accidental coupling. We’re doing the opposite:
- Separate products for distinct jobs (taxes, books, and more over time).
- Shared foundations where it matters (tokens, UI patterns, versioning).
- Explicit contracts between services (OpenAPI).
- A single discovery and snapshot layer (MCP) so tooling can stay coherent across repos.
This is slower up front, but it’s steadier long term. It gives us a clean way to evolve each product without breaking the rest of the ecosystem.
What you should expect from us
We’re building tools that behave like reliable instruments:
- They tell you what they know and what they don’t.
- They keep a trail you can revisit.
- They let you export your work in predictable formats.
- They don’t hide behind “AI said so.”
If that resonates with you, follow along. We’ll keep sharing how the system is designed and why.