Real production client work, anonymized. No public demo by design: the system belongs to the client. Delivered and accepted.
The billing bot was quietly giving everyone double the subscription.
A content creator's subscription business ran on a Telegram bot with a React mini-app. It was granting 60-day subscriptions instead of 30 and skipping tier price step-ups, while an expiry job threw ~880 errors a day. I root-caused it, fixed it under TDD, and shipped the fix to production safely.
The impact
A live system billing real users. Every number here was confirmed in production, not in a sandbox.
The brief
The problemA live billing system, quietly wrong.
A content creator was selling paid subscriptions through a Telegram bot with a React mini-app. On the surface it worked: people subscribed, payments went through. Underneath, every subscription came out at 60 days instead of 30, tier price step-ups were silently skipped, and a background expiry job was throwing roughly 880 errors a day. No one knew why. Every day it kept running, the business handed out double the product at yesterday's price.
The rescueFind the cause, prove the fix, ship it safely.
The root cause was a duplicated background scheduler: two instances running side by side, double-firing subscription jobs. That single defect explained both the 60-day grants and the skipped price step-ups.
Every fix went in under TDD: first a failing test that reproduced the bug, then the fix, then regression tests to pin the corrected behavior. The same pass eliminated the expiry job that was throwing ~880 errors a day.
Shipping was treated as part of the fix. The deploy went out in a zero-traffic window with a snapshot ready for instant rollback, and the whole flow was then validated end to end on real test payments: correct 30-day grants, correct tier prices. The client accepted the work with the system live.
Under the hood
- Reproduce firstNo fix without a failing test proving the bug exists.
- One root causeThe duplicated scheduler explained every symptom; fixing it fixed the class of bug, not one instance.
- Regression as contractTests pin the corrected behavior: grants and step-ups cannot silently regress again.
- Deploy as part of the fixZero-traffic window, snapshot rollback, and a staged rollout on a live paid product.
- Validate like a userReal test payments through the real flow, in production, before calling it done.
Got a live system quietly doing the wrong thing?
This one was rescued without drama: root cause found, fixes proven by tests, shipped in a safe window, validated on real payments. Yours can be next.