$10M+
saved in intermediary fees
As the lead engineer, I redesigned the recharge flow to integrate directly with telecom operators. It handles 7M+ daily orders and has had zero outages.
← All work 
Google
Software Engineer · India · 4+ years · Jul 2021 – Aug 2025
4+ years building payments infrastructure for Google Pay’s bill-payment and recharge business in India serving 12M+ daily orders.
My work spanned
- Building new systems
- User-facing features
- Data analysis & diagnosis
- System reliability
- Oncall (200+ pages/week)
- Tech lead for 2 engineers
- Cross-functional alignment
- Internal hackathons
Key Highlights
$25M+
revenue venture's invoicing platform
I owned it from design to production and aligned Business, Tax, UX and external partners. It earned me a Director’s Spot Bonus.
300K+
stuck orders released (99%)
I root-caused order-state inconsistencies, then shipped monitoring so it wouldn’t happen again.
46K+ → 0
throttled orders during bank outages
I built a caching layer for bill-payment and recharge flows, which prevented ₹4.6M+ in lost transactions.
2.80% → 1.28%
bill-payment failures, 12M+ daily orders
I routed traffic to partners’ higher-availability APIs during off-peak windows with zero regressions, and earned a tech-lead bonus.
How I Worked
- Owning the product. For nearly all my projects, I took on the Product Manager role, gathering requirements and worked across Business, UX, Tax, Legal and third-party vendors to define what we built.
- Leading engineers. I scoped projects, ran design reviews and reviewed code for two engineers on my team.
- Shipping carefully. I rolled features out gradually, watched A/B metrics, and rolled back when the numbers didn’t hold up. On systems handling millions of daily orders, being able to undo a change mattered as much as shipping it.
- Debugging the hard way. This was before AI coding agents, so I traced bugs by hand through unfamiliar codebases and hunted down edge cases myself. That built the instinct I still rely on for figuring out where a system will break.
How I Grew
- Redesigning is harder than building from scratch. You inherit undocumented edge cases and millions of users who can’t afford a regression.
- Get decision-makers in one room. Aligning stakeholders one by one is slow and drifts. Putting everyone together to settle a decision is usually faster and holds better.
- Under a hard deadline, use existing expertise. On a high-priority project, it’s better to rearrange the priorities of the person who already knows the technology than to give the work to someone who has to learn it first. Growth opportunities belong on projects that can absorb the ramp-up time.
- Whiteboard. For early design discussions, a whiteboard gets people agreeing much faster than a long document. The doc is for recording what was decided.
- Good engineering doesn’t guarantee business results. Not every project I shipped hit its targets, even when the engineering was solid. I learned to check the business assumptions early, so problems show up before launch rather than after.