Case study · Kifpool.me · Reliability
Releases that protect people’s money
Crypto markets move fast, and the busiest moments are exactly when an exchange can least afford a broken release. I made release plans, staged rollouts, rollback paths and monitoring a standard part of shipping anything that touches financial data.
- Role
- Technical Product Manager
- Applies to
- Changes that touch financial data
- Practice
- Flags, staged rollouts, runbooks
- Standard
- Rollback path before launch
The situation
Kifpool.me handles thousands of transactions a day across trading, custody and settlement, and crypto prices can move sharply within minutes. Users expect the app to work best exactly when the market is busiest.
The problem
Speed and safety pull in opposite directions. The team ships every two weeks, and some of those changes touch balances, orders or prices. A release that goes wrong at the wrong moment costs users money and trust, and trust is hard to win back.
What I did
- A release plan for anything that touches financial data: what changes, how it rolls out, what success looks like, and the exact conditions for rolling back.
- Feature flags and staged rollouts. New behaviour reaches internal accounts first, then a growing share of users, then everyone. The kill switch is tested before launch, not during an incident.
- Nothing ships blind. Before a new service reaches production it needs structured logs, at least four key metrics, two alert rules and a basic runbook.
- A second look where it matters. Changes to financial logic or concurrent operations get a focused review, instead of treating every pull request the same.
- Blameless postmortems within 48 hours of a serious incident, with action items that feed straight into the risk register.
“Facts first, cause second, prevention third.”
Results
What I learned
Reliability is a product feature. Users never see the release plan, but they feel it on the days the market is busiest.