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 2026

To company-wide adoption

40 days PMs, engineering managers and engineers

Microservice repos

100+ 47 active in ProdE

New-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."

Vishal Gupta · Founder & CEO, DIRO

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

BeforeAfter (client reported)
Senior leaders and every stakeholder in one room to work out a changeAnyone asks ProdE, from anywhere
Everyone needed in the officeA remote working culture
Documentation kept by hand in ConfluenceGenerated from code; nobody maintains it
Agent sessions re-explore the repos every timeIndexed 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."

Tanya Srivastava · Head of Engineering, DIRO

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

MetricResult (as of Oct 2026)
Time to get running1 day
Time to company-wide adoption40 days
Codebase100+ microservice repos, 47 active in ProdE
Who uses itPMs, engineering managers and engineers
Planning in ProdE68 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.