You are the engineering manager responsible for launching a new identity verification workflow for a B2B fintech platform that enterprise customers are waiting on for contract renewals this quarter. The new workflow depends on a rules engine that has become difficult to change: release cycles have slowed, incident volume has risen, and two recent customer escalations were caused by regressions in adjacent rule paths. Your staff engineer is arguing for a 6-week refactor of the rules evaluation layer before adding new capabilities, while the GM wants the customer-facing workflow shipped in 10 weeks and has already previewed the launch to Sales. A compliance lead is concerned that continuing to layer new logic onto the current system will make audit evidence harder to produce, but the platform team can only spare one engineer because they are also supporting Alloy’s core onboarding flows. You need to decide how much refactoring to fund now versus what can safely wait without putting the launch or system reliability at risk.
| Detail | Value |
|---|---|
| Delivery deadline | 10 weeks |
| Backend engineers | 4 |
| Frontend engineers | 2 |
| Shared platform engineer | 1 part-time |
| Current rules engine incidents | 5 Sev-2 incidents in last 2 quarters |
| Enterprise customers tied to launch | 6 |
| ARR at renewal risk | $4.2M |
| Compliance requirement | Auditable rule decisions retained for 7 years |
| Allowed launch scope | One workflow, two customer-configurable rule types |
How would you decide whether to invest in refactoring now versus shipping on the current architecture, and how would you plan execution so you can meet the business deadline while controlling reliability, compliance, and stakeholder risk?