1 min lesson
Build-vs-buy turns on time, scale and complexity
Answer this: "Sales needs a quote-approval rule the CPQ tool can express with native approval workflows, but it would take some clicking to set up. An engineer on the team offers to write a custom service instead. What's the stronger call and why?"
Step 1 of 2
Build-vs-buy turns on time, scale and complexityplus your appetite for risk
Cursor's own finance team built their contract-provisioning automation rather than buying it. Buying would have meant system integrations, vendor onboarding and time they didn't have, and they had no spare engineering resourcing to throw at it. So they built. But the same team will tell you to buy when the problem is genuinely complex or a strong dedicated tool already exists - replicating that in-house is the over-build trap in a different costume.
Don't pitch a build-everything worldview. The deciding factors are time, scale and complexity. Build where there's a true unaddressed pain point that's blocking scale, and buy where a dedicated tool already does it well.
“People have been talking about SaaS apocalypse, right? And I don't quite buy into that statement.”
Have one real story where you chose to build and one where you chose to configure, each with the consequence. The build story is stronger if it includes a cost you paid later - the integration you had to babysit, the test suite you wish you'd written sooner. The configure story is stronger if it's where an engineer would have over-built and you didn't. Showing you can resist your own instinct is the point.