Self-Build vs. Single Module vs. Modular Solution: How to Compare Retained Work in EV Charger Projects

Choosing a charging module solution is a retained-work decision, not an assumption that a package contains an entire charger. A product team may build the power stage, purchase a single module, or combine a module pack with control and system components. The route is useful only when the buyer can name the work it will still own and the evidence that will close it.

For an EV charging solution, use one primary artifact: a Three-Route Comparison Table.

Freeze internal capability first

Before comparing packages, record whether the product team can own controller and firmware, power-path and cabinet design, vehicle and connector integration, certification coordination, manufacturing/change control, deployment and service. Mark each capability as owned, conditional or requiring a defined external scope. This is an internal baseline, not a supplier score.

Compare the three routes

The table frames retained work; it does not rank routes or suppliers. A package label such as “solution” or “platform” cannot close an unassigned row.

Read the table in the same order that the programme makes the decision. First freeze the product requirement and the layer being sourced. Then check the operating and interface evidence for that layer. Next assign integration and complete-configuration testing. Finally confirm the manufacturing, change-control, acceptance and service rows that matter to release. If a later stage changes the configuration, reopen the affected row rather than carrying an early route choice forward by habit.

Keep product and system evidence separate

A module row can contain model-level output, current, constant-power, temperature, cooling or interface evidence. It does not automatically prove the complete charger’s cabinet, connector, HMI, payment, backend, site acceptance or certification. A module pack or PMU must have a named configuration and responsibility boundary; do not infer a fixed BOM, redundancy or service scope from a diagram.

When the route includes an EV charger module supplier, ask which object is quoted, which interfaces are included and which work remains with the buyer or integrator. A supplier can answer a component question without owning the released product.

Compare risk ownership by route

For each route, write one owner beside five risks: architecture, integration, compliance, supply/change and deployment. Architecture asks who approves the electrical and control boundary. Integration asks who diagnoses faults across module, controller and vehicle layers. Compliance asks who maintains the configuration used for the test. Supply/change asks who controls approved substitutions and product changes. Deployment asks who owns commissioning, handover, spares and field response.

These rows make the route reversible. If an interface is unowned, a certification task has no owner, or service scope cannot be contracted, the route should remain conditional. The absence of a problem in a diagram is not evidence that the buyer has accepted the responsibility.

Keep a short route decision note with the requirement baseline. It should state the selected route, retained functions, evidence already received, open dependencies, decision owner and next review date. If the team later changes from a single module to a module-pack route, the note should show which responsibilities moved and which tests must be repeated. This is more useful than treating a broad package description as a permanent answer.

Keep company and service evidence on a separate track

For factory, capacity, MOQ, lead time, active-sale, regional supply or SLA claims, request current official company or contract evidence only when the make-or-buy decision depends on them. Do not infer these points from a catalogue, a broad supplier label or a solution-platform diagram. Product Manual evidence supports named product/model rows; it does not fill the company answer.

UUinside material can provide architecture context, including ACU, PMU, DCU, DSU, CMS and optional POS concepts, and can help the team formulate questions. It does not by itself establish a fixed SKU/BOM, turnkey, OEM/ODM, white-label or service commitment for a project. Keep the commercial route open until the configuration and statement of work are defined.

The same separation applies to an existing charger family. A team may already own a controller, cabinet or acceptance process, while another team may need to create all of them. The route table should therefore be completed for the actual programme, not copied from a generic supplier presentation. It should identify what is reusable, what must be redesigned and what evidence proves the reuse is valid.

Set reversible exit criteria

Before approving a route, confirm:

• the product layer, model or component set is named;

• retained interfaces, integration and acceptance owners are assigned;

• component and complete-configuration evidence are separate;

• manufacturing, change-control and service evidence is available where required;

• every conditional row has an owner, next document and review date.

If a technical boundary is clear but company or service evidence is missing, proceed only with conditions. If a missing interface or configuration fact could change viability, hold the route. None should be selected simply because a package label sounds complete.

Before you choose a route

A sound make-or-buy decision leaves a trail from capability to evidence. Self-build, single-module and modular-solution routes may all be valid in different programmes; the buyer should choose the route whose retained work it can own and whose open evidence has a closure path. UUGreenPower context can help identify what to verify, but it does not turn a charging module solution into a complete charger offer.