Avinash Bussa

For months the single most requested thing was a chat style interface. Users said they wanted to talk to the product instead of clicking through it. We built it, shipped it and watched core metrics slide within two weeks. The people who asked for it used it a few times and drifted. The format had changed how they related to the tool from reflecting on what they were doing to just asking for an answer. We pulled it and replaced it with something guided with pauses built in. That version worked better than both. But we only found it because we questioned why the request existed, not just what it was. How do you separate "users want this" from "users will actually use this" before you build it?

Hi everyone, I'm Shashank, founder of TraceX.

We're building TraceX because of one message every engineering team knows: "My refund never arrived." Someone drops what they're doing, queries the database, greps the code, reads last week's deploys, checks the logs, and an afternoon later finds the cause. In our demo it's a migration that renamed a state a background worker still filtered on.

Our AI employees have names. Peter is an SDR, Kavya sells insurance, Arjun is a loan officer, Priya handles renewals.

We did it because customers found it easier to talk about "Peter's pipeline" than "the lead qualification workflow." Teams started treating the agents like colleagues with a job, which made it easier to define what each one owns.