It is easy to build a financial software demo that impresses a room. It is much harder to build a tool that a credit analyst actually reaches for at ten in the evening when a deal is due at committee the next morning. Those two goals pull in different directions more often than people expect, and we have tried to consistently choose the second one.
Time in the seat before time at the whiteboard
Before writing a line of product spec, our team spent extended time sitting with analysts at direct lending shops, watching how a memo actually gets built, where the friction genuinely is, and which parts of the process analysts complain about versus which parts they have simply stopped noticing because they have done them so many times.
What we learned by watching, not asking
Asking an analyst what they want tends to produce a wish list of features. Watching them work produces something more useful: a map of where they lose time without realizing it.
- Analysts spend far more time re-formatting and reconciling numbers between systems than they spend on actual credit judgment.
- The most valuable minutes of an analyst's day are spent thinking about downside scenarios, not typing.
- Trust in a tool is built or destroyed by a small number of high-stakes moments, like whether a pulled number matches the source document exactly.
Designing around how analysts actually check work
A credit analyst does not read a system's output the way a casual user reads an app. They check it, line by line, against the source, because their name and their firm's capital are attached to the conclusion. Every design decision in AZ2 assumes that scrutiny is coming and tries to make it fast rather than trying to avoid it.
Citations as a design principle, not a feature
Every number the system surfaces links back to the exact page and location it came from. This was not an add-on. It shaped the underlying architecture from the start, because a credit tool that cannot show its work is not a credit tool an analyst can rely on when it matters.
We did not set out to build something that looks impressive. We set out to build something an analyst would trust with a number they are about to put their name on.
What we chose not to build
Saying no to features is as important as building the right ones. We deliberately avoided building generic chat interfaces that answer any question about a document without grounding, because that pattern produces confident-sounding answers that are not reliably correct, and confidence without accuracy is worse than no answer at all in this domain.
How this shapes our roadmap
Every feature request gets evaluated against a simple question: does this help an analyst move from source document to verified conclusion faster, or does it just add another button. Requests that come from actual working analysts, describing a specific moment of friction in their week, get prioritized over requests that describe a hypothetical capability.
Why this approach compounds
Building close to the actual workflow means the product gets sharper with every deal team we work with, because the feedback is specific and grounded in real files, not abstract feature requests. That is a slower way to build a company than chasing what demonstrates well, but it produces a tool that keeps earning trust after the first impression wears off, which is the only kind of trust that matters in credit.
