Resolve a low-code versus custom-build conflict

WHAT THIS TESTS At principal level, you are expected to dissolve a strategic standoff with data, not authority. Both VPs hold partial truths: speed is real, and so is lock-in. The interviewer wants to see you reframe the binary into a scoped, testable, reversible decision.

A GOOD ANSWER COVERS First, extract the actual concerns. Speed-to-market and lower staffing on one side; scalability ceilings, customization limits, and innovation lock-in on the other. Then de-risk empirically: build a time-boxed proof of concept on the low-code vendor that deliberately stresses the riskiest requirements, peak load, a complex custom workflow, a deep third-party integration, and the escape hatch when the platform cannot express something. Measure where it breaks. Quantify total cost of ownership including license growth, and quantify exit cost if you must migrate off later. Finally, recommend a hybrid drawn along the line of differentiation: use low-code for commodity internal tools and undifferentiated CRUD, keep the scalable, differentiating core in code you control. Present a reversible first step, not an irreversible bet.

COMMON WRONG ANSWERS Siding with engineering or product on principle. Ignoring exit cost and vendor lock-in. Offering a pure binary, all low-code or all custom, when the right answer is partitioned by what creates competitive advantage.

LIKELY FOLLOW-UPS How do you decide which workflows are differentiating versus commodity? What does an exit plan from the vendor look like? How would the POC's failure modes change your recommendation?

ONE CONCRETE EXAMPLE You prototype the core transaction engine on the low-code tool and it cannot meet the p99 latency target or express a needed custom pricing rule without brittle escape hatches. You show that internal admin dashboards, however, ship three times faster on it. You recommend admin and back-office on low-code, transaction core in custom services, plus a documented exit path, turning a deadlock into a scoped plan.