All previews
EVSE Engineering460 wordsnot yet seeded

EVSE Pre-Production Readiness Checklist

What has to be true before a charger design enters production: documentation that someone else can build from, test coverage that catches drift, and closed issues rather than known ones.

Technically reviewed by Anees P K, Director of Technology. Last reviewed 2026-09-01.

Production readiness is not a date. It is a set of conditions, and the useful version of this checklist is the one you cannot argue your way past when a shipment is late.

Most of what follows is documentation and evidence rather than hardware, which is why readiness reviews are often deferred: nothing visible is missing.

Design is frozen and the freeze is real

A frozen design means changes require a controlled process rather than a conversation. Where changes are still arriving informally, the documentation cannot be trusted, and every downstream artefact built from it decays.

The test is not whether anyone intends to change it. It is whether a change can happen without the process noticing.

Documentation somebody else can build from

The honest check is whether someone who did not design the product can build one from these documents alone. If the answer requires a phone call, the pack is not finished.

  • Bill of materials with manufacturer part numbers and an approved vendor list.
  • Drawings with tolerances that can actually be held rather than aspirational ones.
  • Work instructions written for an operator, not a summary written for an engineer.
  • Process flow with station definitions and cycle time expectations.
  • Test specification with limits derived from characterisation.

Test coverage against real failure modes

End-of-line coverage should trace to the process failure analysis. Coverage assembled from what is convenient to measure leaves the gaps where assembly defects actually occur.

Limits must come from characterising the product rather than from the specification, or the line will spend its first months arguing about whether failures are real.

Issues closed, not listed

Every programme reaches this point with an issue list. What matters is whether each item is closed with a root cause and a verified fix, or carried forward as known and accepted.

Carrying items is legitimate when the acceptance is explicit and someone senior owns it. It becomes a problem when the list is simply inherited by production, who did not agree to it.

The supply chain can actually deliver

Approved parts available at the volume and cadence the plan assumes, with lead times understood and single-sourced items identified. A design that is ready and a supply chain that is not produces a line that cannot run.

Long lead items and sole sources are the two that stop production, and both are knowable well before this point.

People and calibration

Operators trained and signed off per station, with records. Every torque, measurement and test device calibrated with an interval and an owner. Without these, the build record cannot be defended and yield data cannot be attributed.

This is the part most often assumed rather than verified, and it is the part an audit checks first.

Certification position understood

What is certified, at which revision, and whether the configuration entering production matches it. Drift between the certified configuration and the built one is the most common compliance finding, and it starts on day one if nobody records the baseline.