Building in public: why using our own product makes us better

6 min read

Last edited:  

Building in public: why using our own product makes us better
Akanksha Deswal
Akanksha DeswalEngineering Leader, DevRev

A conversation between Akanksha, Head of Engineering India (and DevU-1), and Ahmed, CTO – on what happens when 250 engineers live on the product they ship.

Link to video

What we learned

When 250 engineers use the product they built, something unexpected happens. Problems surface not in quarterly reviews, but on Monday morning. The clustering algorithm that worked fine for hundreds of tickets? It breaks when support loads thousands. The search that sales loved? It doesn't answer what engineering needs.

DevRev calls itself Customer Zero. Everyone – from the CTO to the support team – runs on the same platform they ship. Not a sandbox. Production. And that changes everything from how they build to how they fix.

Customer zero, user one

DevRev has been its own alpha environment since day one. Every team – engineering, sales, and support – operates on DevRev daily. It's not a sandbox. It's production.

Akanksha carries the internal identifier DEVU-1. User one. The very first person to onboard onto the platform. And DevRev the organization is Customer Zero – 800 people, five years of history, every department running workflows through the same system.

When you're building a company, if you can actually use your own product – live on the product – that helps everything get revealed faster

From Ahmed's perspective as CTO, this isn't just about convenience. Running on your own infrastructure at scale surfaces failure modes that staged environments never reveal. When your own authorization system has to handle 800 employees with varying roles, when your clustering algorithm chokes on real ticket volumes, you fix it before a customer ever sees it.

When dogfooding reveals what specs can't

DevRev's customization engine exists because the internal team needed an object type that didn't exist as a stock object. They built it, used it, demanded search treat custom objects as first-class citizens, and insisted analytics work across them. By the time customers got it, it had been pressure-tested by the people who built it.

The same happened with MFZ, DevRev's authorization platform. It had to enforce policies on objects it had never seen – including custom objects – with field-level access controls. As the org grew from a handful to 1 to 800 people, external tools connected into the platform, and access provisions from those systems had to be respected. The authorization system was enterprise-ready before enterprise customers arrived.

Innovation at the boundaries

Clustering: Four years ago, DB-scan worked perfectly for engineering teams clustering hundreds of issues. Then support tried it with thousands of tickets – and it broke. What followed: hierarchical DB-scan, then LLM-based classification, then a multi-tiered k-means redesign. None of this would have happened if only one department used the product.

Search → Text-to-SQL: Search worked great for sales – pointed objects, graph navigation. But EPD teams needed collection answers: what's the summary of my sprint? That's an aggregation question, not a search question. This insight led to Computer – DevRev's Team Intelligence platform – developing a natural SQL translation layer, now powering dashboards and analytics across the platform.

Search is not enough alone – we need text-to-SQL and an ability to be able to go over like a collection of objects to be able to answer that question

Ops as a real-time feedback loop

DevRev's microservices connect to Argo CD, CircleCI, and other CI/CD tools – all flowing into the platform. Engineering leaders query Computer in natural language for real-time visibility.

In the live demo, Akanksha asked Computer about test status for Janus (identity and access management). It reported pass rates below target, identified degraded QA percentages, and surfaced the most unstable test suites. She created an issue on the spot, assigned it to the right engineer, and tagged it with the correct product – all in minutes.

Typically you'd have a big rev-ops team building dashboards, and by the time you have a dashboard the information is already stale. This is real-time

Ahmed noted that this shifts how engineering leaders operate. Instead of waiting for escalations or quarterly reviews, you see the problem and fix it while the context is still fresh.

That's actionable memory in my mind. The ability to actually enrich the information so that you understand the work that's happening, the product, the customer that it's serving, but then also who's working on it

The customer in the sprint plan

Why should sales, support, and engineering all use the same product? The answer became obvious when customer signals appeared in the sprint plan – connecting work items to customer tickets, opportunities, and upsells.

Keeping the customer at the center of it is really has always been the answer at DevRev. Why do you want to do it? Because you know a certain customer needs it

Because all data lives in Computer's memory, you can ask "how much of my work is justified by customer demand?" and get real answers – then turn them into dashboards the whole org tracks.

Tools for one, tools for many

Some Team Intelligence tools help you personally: summarizing meetings, updating your project status, answering questions you'd otherwise spend an hour researching. That's useful.

But the bigger shift happens when those same tools become shared. When a pipeline health skill that one engineer built spreads to the whole leadership team. When insights from a customer call become visible to product and support simultaneously.

DevRev used to maintain "day in the life" guides for every role. The pattern was predictable: some people adopted quickly, most lagged, a few never caught up. Team Intelligence changes that distribution. The best still excel, but now everyone has the same baseline tooling. You get the reminder daily, not in a quarterly review.

We call it team intelligence. It's the know-how that exists in the company, but it's not necessarily distributed fairly. What we're trying to do is elevate everybody by making sure that knowledge continues to be the great equalizer

This post is based on a LinkedIn Live conversation between Ahmed (CTO) and Akanksha (Head of Engineering, India) at DevRev. Join us on [Discord](https://discord.gg/devrev) to see what we're building behind the scenes.

Akanksha Deswal
Akanksha DeswalEngineering Leader, DevRev

Corporate Director of Engineering, DevRev