How Long a Custom Battery Pack Program Actually Takes

Which of the three programs are you actually running?

Most published development timelines average across programs that have almost nothing in common. A pack that needs a logo and a pack that needs a new architecture for a submarine are different projects with different teams, budgets and clocks. PBC scopes every inbound program into one of three lanes on the first call, because nothing else about the schedule conversation makes sense until that is settled.

White label: 2 to 4 weeks

The fastest lane: an existing, already-certified off-the-shelf pack produced under your brand. Label, colors, documentation, packaging. No design change. From kickoff to first branded sample is typically 2 to 4 weeks, and these programs usually carry no NRE fee.

The certification consequence is the point schedules most often miss: because branding is not a design change, a white-label program almost never triggers UN 38.3 retesting. The Manual's new-type test (§38.3.2.2) turns on changes that could lead to failure of a test, and its example list names things like protective devices, cell count and cell connection mode, not labels. If anything beyond cosmetics moves, put the question to your lab in writing; if nothing does, the existing report should carry. If an off-the-shelf pack in our catalog meets the spec, this lane is hard to beat on time-to-revenue.

Reference-design custom: 9 to 16 weeks

The most common program at PBC. The starting point is a proven reference design, and the delta is real but bounded: the enclosure dimensions shift to fit your envelope, or parallel strings are added or removed to move capacity, or the connector and comms interface changes. For a straightforward design, an LFP pack built on prismatic cells for example, the program runs 9 to 16 weeks to first article, not including any recertification the changes trigger.

The speed comes from what already exists. PBC maintains reference pack and module designs across most chemistries, including NMC, NCA, LFP and LTO, in the common cylindrical and prismatic formats, so a program rarely starts from a blank page. NRE in this lane is nominal: as an industry-typical illustration, on the order of tens of thousands of dollars up to the low hundreds of thousands, driven mostly by certification scope. Structurally, suppliers (PBC included) frequently absorb or credit NRE when the customer commits to a multi-year supply agreement, which aligns both sides on getting to production.

One honesty note on that asterisk: the "excluding recertification" carve-out is doing real work in this lane. Adding or removing parallel strings changes the number of component cells, which is exactly the kind of change the Manual's new-type provision (§38.3.2.2) names, and a capacity change beyond 20% triggers it outright. If the variant changes capacity, plan the certification clock into the calendar rather than treating it as a surprise.

Clean sheet: 6 to 18 months

The third lane exists for requirements no existing architecture can meet. Two examples from the current market. First, hybridizing existing equipment, where the battery must package into whatever space is left in a machine that was never designed to carry one, so the pack architecture is dictated by an extreme space claim. Second, the new power class of data-center UPS: NVIDIA's published 800 VDC architecture work states that "the legacy 54 V standard has become a bottleneck" as data centers turn into AI factories, and batteries that ride on an 800 V bus at high power density are a different design problem from a 48 V telecom shelf.

These programs develop new pack and module architectures, and the calendar goes where the engineering goes:

• Mechanical validation. Batteries are heavy, and the structure is full of stress points, cell interconnects above all. Shock and vibration performance has to be engineered and then proven, and mechanical failures are exactly what transport testing punishes: per In Compliance Magazine, most UN 38.3 failures happen at the T.3 vibration test.
• Thermal modeling. High power density concentrates heat; some programs live or die on the thermal design.
• Custom BMS. Custom communications and protocols, security requirements, EMI hardening. Firmware scope is a frequent and underestimated schedule driver.
• Custom tooling. Clean-sheet packs almost always need their own tooling: soft or hard tooling for injection-molded parts, cast enclosures. Tooling is a long-lead item and belongs on the critical path from day one.
• Extreme acceptance criteria. Military programs are the clearest example. The Navy's lithium battery safety manual (NAVSEA S9310-AQ-SAF-010 Rev 3) sets platform-dependent passing criteria for abusive testing built around the maximum credible event, "the most severe outcome, or classes of outcomes, produced from a single point failure." For ships, the passing criteria include "complete containment of all flames" from that event alongside pressure limits; submarines go further, requiring containment of all vented material with "temperatures measured below 100 °C." Outcomes short of those bright lines are assessed for risk mitigation under the conditions of use, and the manual's model rechargeable-battery test program consumes a minimum of 18 test assets. Designing a pack to contain its own worst single-point failure is a different discipline from passing a transport test.

Clean-sheet programs run 6 to 18 months to first article. As an industry-typical illustration, NRE for this class of program runs to seven figures, and the standard commercial structure is to amortize it over a production period, with the supplier sharing part of the cost, rather than invoicing it all up front.

*Excluding recertification. Spans run from program kickoff to first article. NRE characterizations are industry-typical illustrations, not PBC quotes; the certification scope is usually the biggest swing factor.

Certification runs on its own clock

Every lane eventually meets the certification calendar, and it compresses poorly. A UN 38.3 program is typically 4 to 6 weeks at the lab, roughly three weeks of which is test and observation time fixed by the procedure itself, plus 10 to 15 days of cycling if samples need the 25-cycle preconditioning, plus building the samples: eight packs for a large rechargeable battery under the Manual's sample table. We took that program apart line by line, including the exemption that can zero it out for module-based architectures, in our UN 38.3 cost breakdown. And UN 38.3 is only the transport gate: where the market requires UL or IEC safety certification, those programs stack on top with their own clocks and sample sets.

The scheduling trap is sequencing: certification testing needs production-representative samples, so it runs after design freeze, at the end of the program, where a failure or a late design change does the most damage. Which brings us to the actual schedule killer.

Where programs actually stall

Not at the lab, and rarely in engineering execution. Programs stall when requirements were not fully defined at the start.

"Programs get delayed when the requirements aren't fully defined at the start. Adding a requirement mid-program means engineering change orders, redoing work that was already done, and in the worst case redesigning a pack after certification. Defining every requirement before the program starts isn't always possible, but it's the surest way to keep schedules under control."Harris Cohn, Chief Commercial Officer, Pacific Battery Company

The mechanics are worth spelling out, because the cost of the same change escalates by roughly an order of magnitude at each program stage:

• Before kickoff: a requirement change is a line in a document. Cost: days, at most.
• Mid-program: the same change is an engineering change order. Completed work gets redone, drawings and analyses get revised, validation may restart. Cost: weeks.
• After certification: the change can make the pack a new type under §38.3.2.2, and the certification you paid for stops covering the product. Cost: months, plus a fresh set of destroyed sample packs.

This is why the requirements-definition phase, the least glamorous part of any program, has the highest return per week of anything on the schedule, and why we push customers to define every program requirement with us before engineering starts: duty cycle, envelope, environment, interfaces, certification targets, and the markets the product will ship into.

Compressing the schedule honestly

Four levers actually work. Pick the least custom lane that meets the requirement, because moving one lane left saves more time than any amount of hustle inside a lane. Lock requirements before kickoff, in writing, including the certification and target-market list. Put long-lead items, tooling, cell supply and certification samples above all, on the critical path from day one. And design the certification boundary deliberately (module-level reports, §38.3.3.1(g) architectures) so that variants and mid-life changes do not send the whole product back to the lab. None of these shortens the engineering; all of them shorten the program.

Frequently asked questions