When to Rebuild vs. Refactor: Lessons from Scaling Keka's BGV Module

We built a background verification module that hit $2.7M MRR in 9 months. Then we threw it away and rebuilt from scratch. Here's why that was the right call—and how to know when to make the same decision.

V1 of Keka's Background Verification module was a success by every metric: $2.7M MRR in 9 months, enabled US market entry, 94% customer satisfaction. So naturally, we decided to kill it and rebuild from scratch.

That decision—to rebuild instead of refactor—was the hardest product call I've made. Here's the framework I developed for when to rebuild vs. refactor in enterprise B2B.

Rebuild when:

1. Your core abstraction is wrong: V1's architecture assumed we'd integrate with 3-5 verification vendors. By month 8, we needed 15+, and each integration took 12 weeks. The abstraction wasn't "wrong," it was incomplete. We'd built for known vendors, not an extensible marketplace. Refactoring would have been painting over structural cracks.

2. Technical debt blocks your strategic bets: V1 couldn't support the workflow automation we needed for enterprise deals. Every workaround added more debt. We calculated: 6 months to refactor vs. 4 months to rebuild with the right foundation. Rebuilding was faster—and gave us the architecture for 3 years of roadmap.

3. You have product-market fit to protect: Paradoxically, we could only rebuild because V1 worked. We had revenue, customers, and credibility. Rebuilding without PMF is just pivoting. Rebuilding with PMF is investing in scale.

Refactor when:

1. The problem is localized: If 90% of your product works and 10% needs rework, refactor the 10%. Rebuilding introduces risk everywhere.

2. You don't fully understand the problem yet: V1 taught us what customers actually needed (spoiler: not what they said in discovery). V2 was built on that ground truth.

3. The team lacks bandwidth for a parallel build: Rebuilds require running two systems simultaneously. If you can't maintain V1 while building V2, you'll ship nothing.

Our rebuild playbook:

  • Built V2 in parallel while V1 served customers (4 months)
  • Migrated customers in cohorts, not big-bang (6 weeks)
  • Used feature flags to gradually roll out V2 modules
  • Kept V1 code running for 3 months post-migration as safety net

Results: V2 cut vendor integration time from 12 weeks to 4, supported 3x more concurrent verifications, and unlocked enterprise deals V1 couldn't serve. Revenue grew 2.4x in the next 12 months.