Custom Necessity
This is one result from the Build-or-Buy Calculator. It describes a situation where your control requirements make buying genuinely painful. You are not building because you want to. You are building because the vendor path would mean fighting someone else's assumptions more than using their product.
What this profile means
Custom Necessity is different from the other build profiles. Build Freely means the scope is small enough that building is easy. Build With Eyes Open means building is a reasonable choice with manageable carrying costs. Custom Necessity means building is an expensive choice that is still cheaper than the alternative.
Your answers pointed toward strong or absolute control requirements combined with stakes high enough that a vendor mismatch would not be a minor annoyance but a genuine operational problem. Whether the control need comes from compliance constraints, workflow specificity, or integration requirements, the result is the same: the buy path would mean adapting your workflow to someone else's product, and that adaptation costs more than building and maintaining your own.
The control premium
You are paying the highest price for software: building and maintaining it yourself. There is no version of this profile where the carrying cost is low. You will spend meaningful time on maintenance, updates, edge cases, and operational work. The question is not whether that cost is high. It is whether the alternative cost is higher.
And for this profile, it usually is. Vendor lock-in research consistently shows that organizations spend significant resources on workarounds when the vendor's product does not match their workflow. The workaround cost is invisible on a feature comparison chart but visible in every frustrated team member, every manual step that should be automated, and every decision that gets delayed because the tool is fighting the process instead of supporting it.
The distinction matters: this is not about wanting control for its own sake. Plenty of people prefer to control things for emotional reasons, because they enjoy the engineering, because they distrust vendors, because they like the feeling of ownership. Those preferences are real, but they are not what drives this profile. Custom Necessity is about needing control because the alternative is structurally worse.
Compliance as a common driver
One of the most common paths to Custom Necessity is compliance. When the tool handles regulated data, when audit requirements dictate how data flows, when the process itself needs to be defensible under review, the vendor's black box becomes a liability. You are not just trusting the vendor to keep the tool running. You are trusting them to maintain the audit trail, satisfy the regulator, and not change something that invalidates your compliance posture.
Some vendors handle compliance well. Many do not. The risk is not that the vendor breaks something technical. The risk is that the vendor changes a default, deprecates a feature, or restructures their data model in a way that quietly shifts your compliance position. You find out during an audit, not during a sprint review.
If compliance is driving your Custom Necessity result, the build path gives you something a vendor cannot: the ability to know, at any time, exactly what the tool does with every piece of data. That certainty has a price. It is worth paying.
How to build when building is necessary
Map what you actually need to control. List every control requirement. Then cross out the ones that are preferences, not constraints. Be honest about the difference. What remains after the crossing-out is the minimum surface you must build yourself. Everything else is a buy candidate. The narrower you make the custom surface, the smaller the carrying cost.
Plan the handoff before the build. Before writing line one, document who handles incidents, updates, and monitoring after you are done building. If you cannot fill that role without yourself, you are building a dependency, not a tool. The build phase is finite. The operations phase is not.
Price the maintenance annually. Custom tools in the Custom Necessity profile are typically more complex than tools in other profiles. More integrations, more users, more edge cases, higher stakes. The maintenance cost per year will be higher than a typical internal tool. Estimate it before you start, and compare it to the cost of a vendor plus workaround approach. If the vendor-plus-workaround is cheaper despite the friction, reconsider whether the control need is as absolute as you think.
Review whether the necessity remains. Control requirements change. Compliance regimes evolve. Workflows shift. The tool you had to build in 2026 may not need to be custom in 2028. Set a review schedule. At each review, ask whether the control constraint that justified Custom Necessity still exists. If it does, keep building. If it does not, the Buy the Relief profile describes your next move.
What this profile does not mean
Custom Necessity is not a blank check for scope expansion. You need to build the core. You do not need to build everything. The periphery, the parts that do not touch the control constraint, can still be bought. Most Custom Necessity tools are hybrid in practice: a custom core that owns the critical logic, connected to bought services that handle the commodity functions. The seams will be ugly. That is acceptable. The alternative, building everything, is not.