Getting a Custom Battery Pack From Pilot Build to Mass Production

Getting a Custom Battery Pack From Pilot Build to Mass Production

A custom battery pack does not move from pilot build to mass production on a date. It moves through a sequence of documented gates whose entry and exit criteria were agreed before the pilot even started, and the pilot build is only the first thing those gates measure. Each gate is proving something different — process capability, documentation completeness, capacity, commercial readiness. Those are four separate claims, usually owned by four different people on the supplier's side, and any one of them can hold the ramp while the other three look green.

I've been in the conference room where that stops being theoretical. Second morning of a pilot build review, whiteboard still carrying yesterday's weld schedule, the program manager leaning back and telling the room they could take production volumes in six weeks. Somebody on my side started nodding. I asked two questions instead: what does process capability look like at the weld and leak stations, and can I see the PPAP element list you're building against. The temperature in the room changed. Not because anyone was hiding anything — because neither of those things had been written down yet, and until they are written down, "six weeks" is a mood, not a plan.

The pilot build is not proving the design

This is the first thing that gets blurred, and it blurs in both directions. The design — cell, BMS, busbar geometry, enclosure, interconnect — should already be frozen or under formal change control before the pilot run starts. The pilot exists to validate the process that will make it: the fixture that holds the module, the torque value and the tool that delivers it with a record, the weld schedule on the tab or busbar joint, the test limits a pack passes or fails against, the work instruction revision the operator is actually following.

If you're still changing the design during the pilot, you're not running a pilot. You're running a prototype build with production paperwork, and everything downstream inherits the uncertainty.

So when I walk a pilot line, here's what I'm looking at. The fixture drawing, at a revision. A torque tool that logs somewhere. A weld schedule posted at the station that matches what the machine is actually running. An operator who can tell me what they do when a pack fails end-of-line test, without looking around for someone to answer for them. If the answer to any of that is "well, normally we…" then the process isn't validated. It's personalized. Personalized processes don't survive a shift change, much less a volume increase.

APQP and PPAP are menus, not checklists

Both frameworks were written for automotive assembly, where a Tier 1 is stamping and welding millions of near-identical parts. A custom pack program is usually smaller, more varied, and closer to the end customer. You have to decide which elements actually apply — and you have to decide it early, at RFQ, not at a gate review three months later when nobody has any leverage left.

The five APQP phases still give you a decent skeleton. What I actually care about when I'm picking elements: a PFMEA that reflects your real process steps instead of a template somebody copied, a control plan that names the characteristic, the spec, the sample size and the reaction plan, MSA on the test equipment because a leak tester that isn't repeatable manufactures false confidence, dimensional results on the pack envelope and mounting points because that's where the pack meets the vehicle, a capacity study rather than a capacity statement, and a PSW signed by someone who can actually sign it.

What I'll waive on a low-volume specialty pack: full automotive-depth PPAP on every line item. A few hundred units a year doesn't justify a 300-piece capability run, and pretending otherwise just burns calendar time that the ramp needs. What I won't waive, ever: frozen design record, controlled work instructions, traceability from cell lot to finished pack serial, and a documented reaction plan for failures.

The mistake I see most often is the opposite of skipping. It's accepting a PPAP binder at the gate that was assembled the night before. Ask when the PFMEA was last revised and what changed. If the answer is "before the pilot," ask what the pilot taught them that didn't make it in. That question usually tells you more than the binder does.

Four gates, four different claims

I think of the transition as four gates. They overlap in practice, but each one stands on its own exit criteria and its own hold point — a named person who signs that the gate is closed.

Process capability comes first, and it's the one that gets confused with the pilot. The exit criteria are capability data on the stations that matter — weld, leak, torque, end-of-line electrical test — plus first-pass yield at a level you agreed in advance, plus evidence that the fixtures on the floor are the fixtures on the drawing. The gate answers one question: can this process make a good pack on Tuesday, and again next Tuesday, or did it make a good pilot pack while everyone was watching?

Documentation completeness is the quiet one. Work instructions at released revision. A control plan that matches what's physically on the floor. A PFMEA updated with what the pilot actually taught you. Test limits with a stated rationale. A traceability scheme that still works when you're shipping a few hundred a week instead of thirty by hand. The gate answers: if your best process engineer left tomorrow, would the line keep running?

Capacity is arithmetic, and I've almost never seen it fully settled in a meeting. I want cycle time at each station, the bottleneck named out loud, the shift pattern, the headcount they're actually hiring to, and the numbers adding up to the volumes in the forecast. Vague answers are the norm — "we have room," "we can add a shift." So I ask what the second shift looks like on paper, and who trains them. The gate answers: is the throughput real, or is it a spreadsheet?

Commercial readiness is the gate engineers tend to skip because it isn't their job, and it's the one that stops ramps anyway. Pricing locked to the agreed volume bands. Tooling ownership and amortization documented. Packaging and logistics defined to the dock. A change-control process both sides have agreed to in writing. A production schedule both sides have signed. The gate answers: does the business arrangement exist yet, or are we still negotiating in the middle of a ramp?

Notice what I didn't list. I didn't list "the pilot passed." A pilot build can pass every functional test you wrote and still fail three of those four gates. That gap is the whole transition.

Where the schedule actually breaks

The date the pilot finishes is almost never the date the supplier can accept production volumes. That isn't laziness. It's lead time living on a different clock.

Cells. BMS boards. And production tooling — the one people forget. The pilot may have been built in a soft fixture, a printed nest, a manual press with a good operator. Production tooling has its own lead time, its own first-article inspection, and its own capability run after it lands. If nobody put tooling lead time on the same chart as cell and board lead times, you arrive at the gate with a beautiful pilot and no way to build the second thousand.

What I do is map three timelines onto one sheet: cell and BMS procurement, tooling and fixture build, and the qualification work that follows tooling — first article, capability run, PPAP submission. Then I look for collisions. There are always collisions.

The risk lives in whatever was informal

This is the part a pilot hides best. During a pilot, a lot runs through the cracks of verbal communication, and the plant is small enough that it works anyway.

The operator who re-torques by feel because the driver setting felt off that morning. The shim somebody taped to a fixture to fix an alignment issue, which never made it into the fixture drawing. The firmware build the pilot units ran that never got a revision number, so nobody can say whether production is inheriting it or something newer. The test limit that got relaxed verbally on day three because too many packs were failing, with no note about why or by how much.

At volume, those become field problems. What I do about it is boring and effective. At the documentation gate, I walk the line with the work instruction in hand and ask the operator to walk me through their step. Anywhere their hands do something the paper doesn't say, that's a finding, not a personality quirk. On firmware, I want a revision number, a release artifact under version control, and a checksum recorded against the units that shipped. Not "the current build." A number.

Set the hold points before you need them

Staged ramp — pilot, pre-production or PPAP run, then serial production — only works if each stage has its own acceptance criteria and a defined hold point where someone with authority signs that the stage is closed before the next one starts.

Write those criteria down before the pilot runs, and get both sides to agree them in the gate plan. The argument you don't want to have is the one where you're trying to define an acceptable yield on a Thursday afternoon while the line is already moving.

One honest caveat: not every program needs all four gates at full depth. A low-volume, low-complexity pack for an industrial application can compress process capability and documentation into a single review, and commercial readiness may already be settled. What you can't compress is the question each gate asks. You can ask it faster. You can't skip asking it.