Skip to content
Not sure what you need yet?Scope your system

Can you customise off-the-shelf software enough? The limits of configuration

Configuring off-the-shelf software gets you a long way — until it doesn't. Here's how far settings, add-ons and integrations can take you, and where the ceiling is.

3 min read
custom software workflow

Configuration can take you a surprisingly long way — settings, custom fields, add-ons, integrations — but every product has assumptions baked in, and once your process hits one of those, no amount of configuring fixes it. The real skill is knowing when you've reached that ceiling, because the trap is spending more and more to bend a tool that was never going to fit.

The short version

  • Configuration adjusts an off-the-shelf product without a custom build.
  • It handles a lot: fields, workflows, add-ons, integrations.
  • It hits a hard limit at the product's core assumptions about how you work.
  • Past that limit, heavy configuration can cost more than building to fit — and still not fit.

What can configuration actually do?

Modern products are flexible. You can add custom fields, adjust workflows, connect other tools through integrations, bolt on add-ons from a marketplace, rename things to match your language, and shape a lot of the day-to-day experience. For businesses that are close to the product's assumptions, this is often enough — and it's cheaper and faster than a custom build.

Used well, configuration is genuinely powerful. It's the reason a good off-the-shelf product can serve a huge range of businesses that all work slightly differently. If your process sits within the range the product designers imagined, configuration lets you tune the tool until it feels made for you. The question is only what happens when your process sits outside that range.

Where is the ceiling?

Every product is built around a model of how a business "should" work. Configuration lets you decorate that model; it can't replace it. When your process contradicts the core assumption, you hit a wall that settings can't move.

The clearest examples are structural. A tool that assumes ongoing memberships can't easily be configured to handle enrolment by term, because the whole product is built around the membership idea. A tool that assumes one flow from enquiry to sale struggles when you actually run three flows in parallel — sale, hire and made-to-order — because it only has one path built in. You can add fields and rename buttons all day, but you can't configure your way to a different underlying model.

What is the trap of over-configuration?

Because the wall isn't obvious, businesses keep stacking add-ons and workarounds to get past it. One more third-party tool to cover a gap, one more integration to sync the thing the core product won't hold, one more manual step to bridge two add-ons that don't quite talk. Each one adds cost, fragility and complexity.

Eventually you're paying more to keep a configured tool limping than a purpose-built system would cost — and you still have the workarounds, and now you have a stack of add-ons to maintain and renew as well. Over-configuration is expensive precisely because it feels like progress: each patch solves a real problem, so it's hard to notice the total has quietly passed the cost of building the right thing.

How do I know I've hit the limit?

  • You're adding a third-party add-on to cover a gap the core tool won't, and then another to cover the gap the first add-on left.
  • Keeping the configuration working takes ongoing manual effort, not just occasional tuning.
  • The "real" process still lives partly in spreadsheets alongside the tool.
  • Nobody fully understands how all the pieces fit together anymore.
  • When you add a new location, staff member or product line, the configuration has to be re-done rather than just extended.

If two or three of these are true, you've probably reached the ceiling. Configuration is meant to save effort; when it starts creating ongoing effort, the balance has tipped.

So configure or build?

Configuration is the right answer when a product is close and the gaps are small and stable. Building is the right answer when the gaps sit at the product's core assumptions, keep growing, and cost real hours to bridge. Neither is universally better — the mistake is not noticing when you've crossed from one into the other, and paying configure prices for what has quietly become a build-sized problem.

The honest first step

If you're not sure whether configuration is enough or you've quietly outgrown it, the answer comes from mapping your process against what the tool can actually do. That shows exactly where the ceiling is — and whether you're better off tuning what you have or building the part that will never fit.

Tell us what you run, and we'll show you what's possible.

One question to start

Let's find out what's actually slowing down your .

That’s the first thing we ask. Tap the word and answer it in your own terms.