Not everything needs to be built from scratch. But not everything should be forced into off-the-shelf software either.
Between “build it custom” and “buy it as-is” lies a spectrum of options that most organizations don’t evaluate systematically. The result is custom software where configuration would have sufficed, or heavily customized platforms that fight their own architecture, or off-the-shelf tools contorted into use cases they were never designed for.
Understanding where your need falls on the build-customize-configure spectrum leads to better decisions and fewer expensive regrets.
Note: This framework assumes you’ve already decided to use a platform rather than build from scratch or partner for the capability. If you’re still weighing those higher-level options, start with “When to Build, When to Buy, When to Partner” for the strategic sourcing decision, then return here for implementation approach.
The Spectrum
Configure means using a platform’s built-in options to adapt it to your needs. No code changes, no custom development: just settings, parameters, and options the vendor designed into the product. Configuration stays within the platform’s intended flexibility. When the platform upgrades, your configurations typically come along for the ride.
Customize means extending a platform beyond its built-in options through code, integrations, or modifications. The platform provides a foundation, but you’re building on top of it. Customization can range from minor (a few custom fields and workflows) to extensive (significant code that changes how the platform behaves). Heavy customization often complicates upgrades and increases maintenance burden.
Build means creating software from scratch, or at least from foundational frameworks rather than finished platforms. You’re not adapting someone else’s product; you’re creating your own. Building offers maximum flexibility but requires the most resources and creates ongoing maintenance responsibility.
Each approach has its place. The mistake is defaulting to one without evaluating which fits the situation.
When to Configure
Configuration makes sense when:
The platform fits your process. If your needs align with how the software was designed to work, configuration gets you there faster and cheaper than alternatives. Fighting a platform’s natural architecture is expensive.
Standard is good enough. Sometimes your process isn’t unique; it just feels unique. If the platform’s standard approach would work with minor adaptation to your habits, configuration may be the right call even if it’s not exactly how you’d design it from scratch.
You want upgrade protection. Configurations that stay within vendor-supported options typically survive platform upgrades. The vendor has an incentive to maintain backward compatibility for features they intentionally exposed.
Speed matters more than perfection. Configuration is fast. If getting something working quickly outweighs getting something perfect eventually, the configured solution may deliver more value.
The risk of over-relying on configuration: forcing your business to adapt to software limitations that genuinely don’t fit. Not every process difference is arbitrary preference; some reflect real business requirements that shouldn’t be compromised.
When to Customize
Customization makes sense when:
Configuration can’t get you there. You’ve evaluated the platform’s built-in flexibility and it genuinely can’t support a requirement that matters. The gap between what the platform does and what you need requires code.
The platform provides real value as a foundation. There’s substantial functionality you’d otherwise have to build: authentication, data management, workflow engines, reporting. Customizing on top of this foundation is still faster than building everything yourself.
The customization is contained. Targeted customizations that extend specific capabilities are more sustainable than pervasive customizations that touch everything. The more you customize, the more you own.
You’re prepared for ongoing maintenance. Customizations need to be maintained as the platform evolves. Updates may break custom code. You need either internal capability or a partner relationship to support what you’ve built.
The risk of over-customization: creating a platform that’s expensive to maintain and difficult to upgrade. Organizations sometimes customize so heavily that they’ve essentially built a custom system, but one constrained by the underlying platform’s architecture rather than designed for their actual needs.
When to Build
Building makes sense when:
Nothing exists that fits. You’ve genuinely looked, and there’s no platform that provides a reasonable foundation for your needs. The gap between available options and your requirements is too large to bridge through customization.
The capability is strategically differentiating. This isn’t commodity functionality; it’s core to how you compete. Owning it completely, with full control over its evolution, provides strategic value that outweighs the cost of building.
You have the resources to maintain it. Building is just the beginning. Custom software needs ongoing maintenance, bug fixes, security updates, and feature development. If you can’t sustain that commitment, building creates liability rather than asset.
The total cost of ownership favors it. When you model the full costs (development, maintenance, opportunity cost), building sometimes wins over years of licensing plus customization plus the constraints of a platform that doesn’t quite fit.
The risk of building: underestimating the ongoing commitment. Organizations sometimes build because they can, not because they should. The result is custom software that works initially but becomes burdensome to maintain as attention and resources shift elsewhere.
The Evaluation Questions
When facing a build/customize/configure decision, work through these questions:
Does a platform exist that fits? Start by understanding what’s available. Many organizations build because they don’t know what exists, or dismiss platforms based on superficial evaluation.
How unique are your requirements really? Challenge the assumption that your needs are special. Sometimes they are. Often they’re standard needs with non-standard vocabulary. If your requirements map to how platforms are designed to work, configuration may be the answer.
What’s the gap between platform capability and your needs? If a platform gets you 80% of the way, customization might bridge the gap efficiently. If it only gets you 50% of the way, you may be fighting the platform’s architecture.
Do you have the resources to maintain what you build or customize? Be honest about your capacity for ongoing maintenance. If you build or heavily customize without maintenance capability, you’re creating future technical debt.
What’s the total cost of ownership? Model the full costs over a realistic timeframe: not just implementation, but licensing, maintenance, upgrades, and the cost of constraints. Sometimes building is cheaper over five years. Sometimes it’s dramatically more expensive.
The Hybrid Reality
In practice, most solutions combine approaches. You might configure a CRM, customize an ERP with specific integrations, and build a proprietary tool that handles something no platform addresses.
The goal isn’t philosophical purity; it’s making good decisions for each component based on where it falls on the spectrum. The same organization might rightly configure one system, customize another, and build a third.
What matters is making those decisions deliberately rather than by default.
Enterprise Engineering helps organizations evaluate build vs. customize vs. configure decisions, and execute whichever approach makes sense for each situation.
Platform Implementation delivers configured and customized platforms that balance capability with maintainability.