Case study · DIRO · Document verification · 100+ microservices
How DIRO built a remote engineering culture on 100+ microservices with ProdE.
Engineering, product and client teams all plan against the real system, from anywhere.
To get up and running
1 day on ProdE since May 2026To company-wide adoption
40 days PMs, engineering managers and engineersMicroservice repos
100+ 47 active in ProdENew-feature tickets planned in ProdE
~60% 68 projects · ~190 tickets"Asking when we use ProdE is like asking if you remember a time you had to breathe oxygen. It's pervasive."
Company profile
DIRO verifies online documents such as bank statements, utility bills and tax returns, pulling them straight from the original source with the user's consent. Its customers are banks, lenders and fintechs meeting KYC, KYB and AML requirements. The platform runs on a microservices architecture of more than 100 repositories, built over six-plus years. 47 of those repositories are active in ProdE, and PMs, engineering managers and engineers all use it day to day. DIRO has run on ProdE since May 2026.
What changed
| Before | After (client reported) |
|---|---|
| Senior leaders and every stakeholder in one room to work out a change | Anyone asks ProdE, from anywhere |
| Everyone needed in the office | A remote working culture |
| Documentation kept by hand in Confluence | Generated from code; nobody maintains it |
| Agent sessions re-explore the repos every time | Indexed once; surgical edits |
The before
At DIRO, every new feature started with one question: which services does this touch? With 100+ repositories built over six years, nobody could easily see who called what. The people who could answer were a few senior leaders.
So every change meant a meeting. "You needed all the stakeholders in the same room to figure out how to implement a change," says Vishal. Even then, something could get missed. It also kept DIRO in the office, because working out a change's impact remotely was harder still.
Bringing someone new up to speed was slow; in Vishal's words, "training itself was a bottleneck." The shared understanding of the system lived in a Confluence space the team maintained by hand, and developers were constantly chased to update it. The team already planned with Claude and Cursor, but each agent session started from zero: it asked the same questions, re-explored the repos, and threw that work away when the session ended.
How it works at DIRO
1. Developers plan like PMs
The shift: "In our company everybody is a PM," says Vishal. Developers write technical specs in ProdE, grounded in how the 100+ repos actually connect, and push the tickets to Jira.
Impact: Tanya Srivastava, DIRO's Head of Engineering, runs 68 projects in ProdE. Around 60% of DIRO's new-feature tickets now start there: about 190 stories, tasks and subtasks.
2. Engineers build with surgical edits
The problem: Every planning session with a coding agent meant back-and-forth questions and re-reading the codebase, and none of it carried over to the next session.
With ProdE: Engineers pick up the Jira tickets and build with Claude Code, with ProdE connected over MCP so the agent can look up exactly what it needs. Even small fixes that skip planning still go through the MCP.
Impact: The codebase is indexed in one place, and the agent makes targeted changes instead of exploring. "With ProdE we've never had a token spend issue," says Vishal.
"Without ProdE, every session we'd re-index the project and it kept taking lots of tokens. Now it's indexed in one place and we just run our queries."
3. Client requests answered from the code
When a client asks for a feature, both the effort estimate and what it involves come from ProdE. The team drafts spec replies to client emails from it too, so answers reflect how the system actually works.
4. A platform-wide change, scoped in one place
To move to loop engineering, DIRO had to standardise log levels across every repo and module. ProdE showed where logging was missing, where it should go, and the implementation status across all repos. Vishal says it helped them move to loop engineering much faster.
The results
| Metric | Result (as of Oct 2026) |
|---|---|
| Time to get running | 1 day |
| Time to company-wide adoption | 40 days |
| Codebase | 100+ microservice repos, 47 active in ProdE |
| Who uses it | PMs, engineering managers and engineers |
| Planning in ProdE | 68 projects · ~190 tickets · ~60% of new-feature tickets |
How ProdE works
ProdE connects to the repositories a team selects with read-only access and indexes them into its knowledge infrastructure: one living model of the whole system, kept current as the code changes. It maps functions, modules and the calls between repositories; generates a wiki for every repository, with architecture and flow diagrams; answers questions in plain English, citing the exact files; and plugs into coding agents such as Claude Code and Cursor over MCP, and into Slack and Jira.
Why it stuck
1. It replaced a meeting, not a tool. The all-stakeholder brainstorm went away, and DIRO moved to remote work because of it.
2. Nobody has to maintain it. The hand-kept Confluence space is gone. Documentation stays complete because it comes from the code.
3. It sits under the tools they already use. Claude Code and Jira stayed. ProdE gave them the context.
Security: ProdE has read-only access to the repositories DIRO selected. It never writes to them and never trains any model on their code. Indexing is static analysis only. ProdE is ISO 27001 certified.
If your two most senior engineers were out for a month, what would slow down first?
Connect your repos and ask ProdE the question you'd normally take to them.