Skip to the work
Nikhith Reddy

  1. Making the signal useful.

    Rapport ·ProductEngineering

    Managers at car dealerships had hours of recordings and no time to listen. I rebuilt the dashboard around four focus cards, with a clear path from a concern to the customer’s exact words.Managers had hours of recordings and no time to listen. I rebuilt the screen to start from a flagged concern and the exact words behind it.I owned it end to end: defined the , designed the path from summary to the exact sentence, and built the frontend and its data contract.Four focus cards lead into , the supporting conversations, and source transcripts. Processing resumes from stored checkpoints.

    But how do you capture conversations when nobody presses record?

    Read the case studyNext stop
    Manager dashboard
    Product · Manager dashboard
    01Give the manager a reason to investigate

    A question worth asking. The words behind the answer.

    <10% manager adoption at the starting point

    Signal Person Conversation

    The finding

    Customer chasing an update

    Alex Morgan · sample visit

    “I was expecting a call yesterday. Can you check the repair status?”Customer · exact words in this example

    Check the promise and what happened next before following up.

    Four focus cards from ten groups. Twenty-eight signals underneath. Hover or focus a card to follow the finding.

    My part The signals, the screens, the frontend and its data contract

  2. Making the AI affordable

    Rapport ·ProductEngineering

    A full day of recorded talk, with voices from the next desk mixed in, had to become clean conversations without an AI bill that grew with every hour.Cost grows with every hour recorded, so I cut what the AI has to read almost in half, and chose the safe setting over the cheapest one.I integrated a third-party AI model, made processing pick up where it failed, and tested every change against real recordings before shipping.Telling speakers apart, finding where conversations start and end, and trimming silence, tuned on of real audio. A cut lost real words, so I shipped .

    Why record the whole day at all?

    Open Rapport · Engineering viewNext stop
    Audio pipeline
    7.61% cut555 of 557 service words kept · the setting I chose
    Remove empty audio, keep the conversation. Each square represents about ten words; outlined squares show the words lost at this setting.
    How these settings were tested

    Every setting uses the same sample of 557 service words. Padding and context also differ, so word retention does not fall steadily as the cut grows.

    An earlier run cut 68.4% and lost 192 of 654 word intervals on a different sample. It failed the safety check.

    My part The AI integration, the recovery and the testing on real recordings

  3. A product that fits the desk.

    Rapport ·ProductDesignEngineering

    I built a browser-based desk app around a microphone, so staff could capture conversations without reaching for a separate tablet. A working prototype took a day; the team rollout followed two weeks later.The app worked, but every forgotten tap was a lost conversation. So I removed the tap.I built the prototype alone in a day, then owned the frontend and interface through a two-week team rollout.Browser audio capture that keeps recording through dropped connections, buffers up to , and replays it in order when the network returns.

    Audio held through outages:

    Why replace an app just as it started capturing conversations?

    Read the case studyCapture was finally climbing. I replaced it anyway.Next stop
    Conversation capture

    Nothing is recorded or sent.

    My part The prototype, then the frontend and interface

  4. Less administration, a clearer next move

    Rapport ·ProductDesignEngineering

    Staff weren't using the first app. I worked through five directions, prototyped three, and revised the winner so accepting a visit never starts recording.Almost nobody used the first version. I treated that as the product's problem, not the people's.I designed the flow and the directions, and built the iOS app with one other engineer.In the revision, accepting a visit and starting capture are separate states, so the screen never implies a recording that hasn't started.

    What was wrong with the first version?

    Open Rapport · Design viewAccepting a visit is not the same as recording.Next stop
    Service flow, iPadTry the revised workflow
    My part The flow, the directions and the iOS app, with one other engineer

  5. The denominator changed the decision

    Rapport ·ProductEngineering

    One store's records showed the widest gap was in how often a recommendation was on record, not in how often customers said yes.The scorecard pointed at selling skill. The records pointed at recommendations that were never written down.I analyzed to find where recorded performance differed.I parsed of free text with pattern matching to measure recommendations on record and yes-rates that no system tracked.

    When the two staff with few recommendations on record had one, customers said yes to of the time

    So why were so few recommendations on record?

    Read the studyNext stop
    Conversation review

    Select a person to read what their row suggests, and what it can’t prove.

    “On record” counts only recommendations for three big repairs that left a trace: a sale, or a written no. A recommendation said out loud and never written down doesn’t appear. B’s 14 and C’s 23 are small samples.
    My part The analysis of the store's exported records

  6. Plugging into what they already use

    Rapport ·Engineering

    Before the product could help, it had to connect to the customer databases businesses already run on, while keeping the app responsive when those systems go offline.Integrations are where startups lose months. I designed this one so the product keeps working while the customer database is down.I designed the integration architecture, led the design reviews with engineering leadership, and wrote the phased plan the team adopted.Transactional outbox, idempotent writes, circuit breakers and rate limits, to isolate delivery failures and make retries safe.

    Retries, replay and duplicate protection, shipped together: in one change, with its own tests

    Where did the habit of checking every number start?

    Read the case studyNext stop
    Change plan
    Keep the app working while changes wait for the customer database.

    Hover a part to see what it does.

    All eight shipped together: in one change, with its own tests.
    My part The integration architecture and the phased plan

  7. A side trip

    ProductDesignEngineering

    On the drive north: a forecasting tool that turns two hours of setup into four minutes, and a fix contributed to Prophet, Meta's open-source forecasting library.Small tools, real time saved.Side projects shipped end to end, including an open-source contribution.FastAPI and Prophet; contributed fail-fast date-range validation upstream (PR #2690).

    Before the code, there was listening.

    Next stop

  8. Two clean-energy startups

    ProductEngineering

    Before the Bay, I consulted for two San Diego clean-energy startups: finding customers for one, making the other's data fast.I found who would actually buy a drone-in-a-box product, across four countries, before anything was built.I ran a sixteen-week customer discovery for one team and built a data pipeline for the other. into one pipeline, with queues, retries and freshness checks.

    Discovery across

    And before that?

    Read the studyNext stop

  9. Where it started

    Engineering

    An AI research lab, where I learned that a model sounding confident isn't proof it's right. That's why every number on this road has its source.Why I measure before I claim.M.S. in Big Data Analytics, then AI evaluation research.I built evaluation sets and regression checks for a multi-agent AI system.

    Objects in the rearview are closer than they appear.