Custom EV Charger Development
Custom is a spectrum, not a category. The useful question is how little you can change and still get what you need commercially.
Teams routinely ask for a new product when a variant would serve, and occasionally ask for a variant when the requirement genuinely needs a new architecture. Both mistakes are expensive, in opposite directions.
Scope your custom programmeFor OEM, product company
Four depths of custom
Swipe to compare
| Depth | What changes | Certification impact | Typical trigger |
|---|---|---|---|
| Configuration | Settings, branding, language, backend | Usually documentation only | Market entry with existing product |
| Variant | Enclosure, connector, power level within platform range | Delta assessment likely | Different market or mounting requirement |
| Derivative | Substantial change on proven architecture | Significant, plan for it | Feature the platform cannot reach |
| New product | Designed from requirements | Full assessment | Category entry or genuine differentiation |
Choosing the depth
Start from the commercial objective rather than the technical wish list. If the objective is entering a market with a compliant product, configuration or variant usually achieves it. If the objective is a product your competitors cannot buy, you need derivative or new.
Ask what happens if each requested change is dropped. Requirements that survive that question are real. The rest are preferences that can wait for version two.
What drives cost
- Certification exposure, which is often the largest single line
- Tooling, particularly for enclosure changes
- Validation scope, which grows with how much of the architecture moved
- Firmware work, especially where new hardware needs new drivers
- Number of variants, because each one multiplies test and documentation
Variant count is the one teams underestimate. Three power levels across two connector types and two mounting options is twelve products to test, document and maintain, not one product with options.
What we need from you
The commercial objective, the target markets and their schemes, the volume forecast by variant, the features that are genuinely non-negotiable, and an honest statement of which requirements are assumptions rather than confirmed needs.
Designing for what comes next
If local manufacturing, additional markets or further variants are likely, the architecture should anticipate them. Designing for a transfer or an extra power level at the start is inexpensive. Adding it afterwards frequently means revisiting decisions that are difficult to unwind.
How customisation is scoped and charged
Customisation covers enclosure and mechanical change, 3D modelling and moulding, connector and cable configuration, display and interface behaviour, and firmware features. It is quoted against an agreed scope and charged hourly rather than as a fixed package, because the range between a colour change and a new moulding is wide.
The practical sequence is usually samples first, so you can test the base platform in your own conditions, then customisation once you know what actually needs to change. Committing to a customisation scope before that step is how programmes pay for changes nobody needed.
When custom is actually the right answer
Custom development is easy to sell and often unnecessary. The honest test is whether a standard product has already failed you for a reason that will not go away.
The customer we localized for in Europe arrived having tried the alternatives. They had sampled one or two units elsewhere, taken white-label software with no data behind it, and bought a charger sold as OCPP whose OCPP was not actually interoperable with what they needed. Each shortcut cost more to unwind than doing it properly would have cost at the start.
That is what makes custom the right call: not ambition, but a specific requirement that a standard product has already demonstrably failed to meet. If nothing has failed yet, sample first and find out.
- 1
Sample
Enough units to see variation and field behaviour, in your own conditions and with your own customers.
- 2
Identify what actually has to change
Usually a shorter list than the one written before the samples arrived, and occasionally an empty one.
- 3
Customise against that list
Charged hourly against an agreed scope, so you do not pay for changes that turned out not to be needed.
Want this applied to your own site?
Scope your custom programmeTechnically reviewed by Anees P K, Director of Technology. Last reviewed 2026-08-29.
Frequently asked questions
How custom is custom?
Four depths: configuration, variant, derivative and new product. Most requirements are satisfied at variant level, and choosing a deeper level than necessary is the most common way custom programmes overspend.
What drives the cost of a custom charger?
Certification exposure, tooling, validation scope, firmware work and the number of variants. Variant count is the most underestimated of these.
Can we start with configuration and go deeper later?
Yes, and it is often the sensible sequence. Launching on configuration while a variant or derivative is developed keeps revenue moving.
Does a custom enclosure require recertification?
It usually requires at least a delta assessment, because enclosure changes affect ingress protection, thermal behaviour and clearances. The determination rests with the certification body.
How do we decide which requirements are real?
Ask what happens commercially if each one is dropped. The ones with a real answer stay. The rest belong in a later version.
Scope your custom programme
Tell us the commercial objective rather than the feature list, and we will tell you the least change that achieves it.
Scope your custom programme