Customization Sprawl: When Every Deal Adds Code
A warehouse management software vendor with 90 enterprise customers had accommodated every customer’s genuinely different processes the way most vendors do at first: custom code per customer — ninety branches of a shared core. Gross margin had fallen from 71% to 54% while revenue grew 40%. Envion attributed eighteen months of engineering time (58% was customer-specific work, largely unbilled) and catalogued all ~1,400 customizations: 62% were configuration in disguise, 26% extension points covered by eleven hook locations, 9% standard-shape integrations, and only 3% genuinely bespoke. The answer was a four-layer extensibility architecture plus a commercial model change — pricing customization instead of bundling it. Thirty months on: gross margin 73%, engineering time on new product up from 23% to 51%, upgrades down to 2–6 hours, 97% of customers on the current version, and €2.9M/year of previously-given-away customization revenue.
The challenge
The client sold WMS software to distribution and 3PL companies. Every customer had genuinely different processes — different pick strategies, different labelling requirements, different ERP integrations, different regulatory constraints by commodity.
They had accommodated this the way most vendors do at first: custom code per customer. Ninety customers, ninety branches of a shared core, with per-customer modifications ranging from a config file to substantial forked modules.
The symptom was commercial. Gross margin had fallen from 71% to 54% over three years while revenue grew 40%. Upgrading a customer took between two days and five weeks and required an engineer who knew that customer. A core bug fix meant ninety merges. Two customers were four major versions behind and effectively unupgradeable.
Their CTO described it accurately: "we're becoming a consultancy that happens to ship software."
Decision path
The economics came first, because the architecture question is downstream of them.
Eighteen months of engineering time, attributed: 23% new product development, 19% core maintenance, and 58% customer-specific work — building, maintaining, and merging custom code. Then the revenue map: custom work was largely bundled into licence deals rather than billed, so more than half of engineering capacity was producing no directly attributable revenue while being treated commercially as free.
That's the margin curve. It wasn't a pricing problem or a sales problem. It was an architectural decision made at customer three, still operating at customer ninety.
Then the more interesting analysis: how different were the customizations, really? All 90 customers' modifications — around 1,400 distinct changes — were catalogued and clustered. 62% were configuration in disguise: different values, thresholds, label templates, field mappings, workflow step ordering, implemented as code because there was no configuration surface. 26% were extension points: genuinely custom logic hooked into a small number of recurring places — eleven hook points covered nearly all of them. 9% were integrations to customer-specific ERPs and carriers: real work, but a standard shape. 3% were genuinely one-off deep modifications, mostly for two very large customers.
Three percent. The architecture was treating 100% of customization as bespoke code because 3% of it was.
Envion contribution
Four layers, each matched to a category.
A configuration engine — versioned, validated, customer-scoped, no deployment required. Targets the 62%.
A plugin model with eleven defined extension points — customer logic in isolated modules against a stable, versioned interface, with the core free to change behind it. Targets the 26%.
An integration framework — a canonical WMS event model, with connectors as declarative mappings rather than code. Targets the 9%.
A supported fork path for the 3% — explicitly priced as bespoke development with its own commercial terms, so the cost is visible on both sides.
The migration was a strangler: new customers onto the new model immediately, existing customers migrated at their next major upgrade, prioritized by how much custom code they carried.
And the trade-offs were stated up front. A stable plugin interface constrains the core — once eleven extension points are public, changing them is a breaking change with a deprecation cycle. Configuration engines can grow into unmaintainable pseudo-languages — so configuration expresses values, mappings and ordering, never control flow, and any request for conditional logic in config is a signal for a new extension point. And migration is slower than a rewrite — roughly 30 months versus maybe 18 for a clean rebuild — but no customer experiences a forced replatform, which for a system that stops the warehouse when it stops is worth more than the time.
Delivery
The commercial change was architecture's business half: stop bundling customization into licence deals. Configuration is free. Plugin development is a priced service. Fork-level work is priced as bespoke development. Without this, the new architecture would have reduced cost without restoring margin, because sales would have kept giving it away — the team had been trained for a decade to close deals by promising customization.
Outcome and evidence
Thirty months on: gross margin recovered from 54% to 73%. Engineering time on customer-specific work fell from 58% to 21%, and time on new product rose from 23% to 51% — the same team, released, without hiring. Customer upgrades went from 2 days–5 weeks to 2–6 hours, customers on the current major version from 61% to 97%, custom code branches from 90 to 3, onboarding from 14 weeks to 5, and previously bundled customization now produces €2.9M a year of attributable revenue.
Architecture and pricing are the same decision viewed from two ends.
| Metric | Before | After |
|---|---|---|
| Gross margin | 54% | 73% |
| Engineering time on customer-specific work | 58% | 21% |
| Engineering time on new product | 23% | 51% |
| Customer upgrade time | 2 days – 5 weeks | 2–6 hours |
| Customers on current major version | 61% | 97% |
| Custom code branches | 90 | 3 |
| Time to onboard a new customer | 14 weeks | 5 weeks |
| Customization revenue (previously bundled) | ~€0 attributable | €2.9M/yr |
Client feedback
What the client says about this engagement
“We knew customization was hurting us. What we didn't know was that only three percent of it was actually bespoke — the rest was configuration and a handful of hook points we'd never built. Cataloguing fourteen hundred modifications was tedious and it's the whole engagement in one exercise.
The recommendation I nearly ignored was the commercial one. Oleg said the architecture would fail to restore margin unless we stopped giving customization away, and he was right, because our sales team had been trained for a decade to close deals by promising it. Changing the architecture and the price book at the same time is what worked.”
From the engagement lead
What I’d tell anyone considering this
“If your margin falls as you grow, look at how much engineering time is attributable to individual customers. That number is an architecture diagnostic, and it's usually available from your existing time or ticket data in an afternoon.
Then catalogue your customizations and cluster them before you design anything. The genuinely bespoke share is always far smaller than the team believes — usually under 10% — and everything hinges on that, because it determines whether you need a configuration surface, an extension model, or a services business.
And change the commercial model alongside the architecture. An extensibility architecture makes customization cheap to deliver. If it's still free to the customer, you've made it cheaper to give away something that was already destroying your margin. Architecture and pricing are the same decision viewed from two ends.”
Evidence gate. This page publishes only what Envion's project records and client disclosure permissions support. Outcomes are added once verified against a baseline, a measurement period, and an approved source.
FAQ
Questions about this case
Facing a similar challenge?
Margins falling as you grow? Catalogue the customizations before designing anything — Envion finds the 3% that’s truly bespoke and architects around the rest.
Discuss a Similar ChallengeKeep exploring
Similar case studies
Executive Technology Leadership
Support for high-stakes product and AI decisions
Bring senior technology leadership into the business when the roadmap is unclear, delivery is at risk, an AI initiative needs stronger ownership, or the company needs an experienced technical voice before hiring a permanent CTO.
Discuss Interim CTO SupportCore responsibilities
- Align product and technology priorities with business goals and measurable outcomes.
- Review architecture, delivery risks, data foundations, security needs, and AI readiness.
- Lead internal teams and external partners through a practical execution plan.
- Clarify team structure, ownership, decision rights, and delivery cadence.
- Support investor, board, partner, and due-diligence conversations with credible technical judgment.
New experience
Prompt-to-Page — try it right here
Describe the landing page you want, in your own words. We turn it into a finished page and email you a private link in 5–10 minutes — no briefs, no calls, $0 to see the result.
- Describe what you want to create.
- We structure, write, and compose the page.
- You receive a private link when it is ready.
Start with a sentence — the interactive builder takes it from there.
Generate My PageSafe, respectful content only. No obligation.