What you actually need (it's four things)
Strip the marketing pages away from this problem and four pieces stand out:
- A written cell acceptance spec, derived from your mission profile — not the supplier datasheet. What current and power profile do your packs actually see in flight? What temperature extremes? What service life? What's the failure mode you can't ship a single instance of? The spec falls out of those answers; the datasheet doesn't know any of them.
- A test plan that can prove or disprove the spec — and that you run the same way every time. What measurements, on what sample size, on what cycle protocols, with what pass/fail thresholds. Concrete enough that a lab tech — yours or a partner's — can run it without you in the room. The discipline of not changing it matters as much as the design.
- A place for the results to live in open formats. Parquet for the underlying time series. Python-readable. Not a proprietary database controlled by your analytics vendor, not 400 CSVs in someone's Dropbox, not a wiki of screenshots. A real data layer your own tools can reach.
- A way to ask questions of those results. Notebooks today — Jupyter, Polars, pandas, your existing toolchain. MCP-driven LLM workflows tomorrow, with your choice of model (Claude, Gemini, GPT, or a local one) looking at your data. If you're a competent Python user, you don't need a GUI to slice a parquet file.
None of these four requires a six-figure platform commitment. The first two require sitting down with your application requirements and a competent battery engineer for a couple of days. The third and fourth are infrastructure questions, and the answers should be modular.
Standardize the test, then leave it alone
The hardest part of running a cell testing program isn't designing the first test. It's running the same test, the same way, for the next three years.
This sounds boring until you've watched a data set get quietly destroyed by good intentions. Someone retunes the chamber from 25°C to 23°C because the lab's HVAC drifted. Someone bumps the C-rate from 1C to 0.8C because the new batch was running a little warm. Someone improves the rest interval between charge and discharge from 30 minutes to 60 because the impedance numbers looked off. Each change is defensible in isolation. Together they mean the data you collected last quarter is not directly comparable to the data you'll collect this quarter, and the trends you think you're tracking are partly real and partly artifact. The cost of the drift is invisible until the day you need to defend a batch decision against a customer or a regulator, and then it is sudden and total.
The right discipline is to design the test once, write it down in enough detail that someone unfamiliar with your program could reproduce it, and only change it deliberately — with a documented reason and, ideally, a parallel run that ties the new methodology back to the old.
A related trap: you may be tempted to design your standard test as a high-fidelity replica of your application's mission profile. It's intuitive — you want to know how the cell performs in your aircraft. But mission profiles change. The customer wants a different payload, the airframe gets a new aerodynamic package, the pack configuration shifts, the cell capacity bumps in the next design iteration. Six months later the test you painstakingly calibrated is measuring a flight nobody plans on flying. A boring standard test — 1C cycle life at 25°C, say — is less informative per data point, but its value compounds across years and batches and product generations in a way mission-specific tests never do. Better to have a standard test than a perfect one. Use occasional pack-level tests against the real mission to validate the abstraction.
Build the lab, or rent one
You don't have to buy cyclers. If you're testing tens to low hundreds of cells per year, you almost certainly shouldn't. Battery testing labs exist for exactly this reason — they own the cyclers, the environmental chambers, the safety infrastructure, and the calibration discipline. You ship cells, they ship results.
- Intertek, SGS, TÜV SÜD — large and multi-discipline. Useful if you also need certifications (UN 38.3, IEC 62133, UL 2054) under the same roof.
- Southwest Research Institute — strong on military and aviation. Long queues, deep competence.
- Smaller specialized battery labs — a handful of good ones in the US and Europe focus exclusively on Li-ion characterization.
If you do want your own cyclers eventually — and most product companies do, around the point where test volume exceeds a couple hundred cells per quarter — the names worth looking at are Arbin, Maccor, Neware, BioLogic, and Basytec. Two notes that will save you money: don't buy more channels than your test plan justifies, and don't pick a cycler because its software is easier to use. That GUI will be a problem in 18 months. The cycler is a measurement instrument; the data layer that sits on top of it is the thing you actually live in.
Where the data lives
Once you have cells under test — in your lab or a partner's — the question becomes where the data goes, and what shape it's in when it gets there. This is where Micantis fits: not as the analytics product that decides whether your cells are good, but as the layer underneath that makes everything else compose.
- Open formats. Your test data lands in parquet, organized by cell, batch, supplier, and test protocol. You can pull it into a Python notebook in three lines. Micantis is not the only thing that can read your data — you are.
- Open tools. Whatever you already use — PyBaMM for physics models, your favorite LLM for ad-hoc analysis, the in-house Python your team wrote — composes against the data layer. Micantis doesn't replace your toolchain; it makes sure the toolchain has clean data to look at.
- Live data. A supplier batch that's drifting should show up in the next pipeline run, not the next quarterly review. The default in this industry is yesterday's analysis on yesterday's data; the bar worth setting is today's analysis on this hour's data.
That triad — open formats, open tools, live data — is the substrate. Analytics on top is your choice. Some teams use ours, some build their own, some plug in PyBaMM and a notebook and never touch a dashboard.
The lock-in cost of closed analytics
The closed analytics platforms in this space ask for six-figure annual contracts and multi-year commitments, and the bill is the smaller of the two costs. The larger cost is that your data lives in a database the vendor controls, behind a UI the vendor designs, with an export path the vendor permits. When you want to ask a question the vendor didn't anticipate, you file a feature request.
For a team that already has a stable, opinionated workflow, that may be a defensible trade. For a team that doesn't yet have a written spec, it's an expensive way to inherit someone else's idea of how battery quality should work, while learning nothing about your own. The right sequence is: open substrate first, written spec next, real test data after that. The platform decision, if you ever need one, comes last — once you know what questions you're actually trying to answer.
Insurance, not analytics
The frame that helps most in conversations with founders in this position: what you're buying, when you stand up a cell qualification program, is insurance. Not analytics. Not dashboards. The ability to say, with evidence, that the cells in the pack a customer is flying tomorrow meet a spec you wrote and can defend.
The cost of being uninsured here is asymmetric. A bad batch in a consumer toy is a refund. A bad batch in a drone flying over a wildfire, or a soldier's hand, or a customer's warehouse, is a different kind of conversation. The premium for getting ahead of that is low when nothing has gone wrong. It is unobtainable at any price the day after something has.
Two ways to start
If the spec problem is uncomfortably familiar, there are two ways to begin — and both leave the data where your own tools can reach it.
Build Your Own — the data-layer subscription
The parquet data layer, the Python API, and organized storage for whatever test data you generate, in-house or from a partner lab. No UI overhead, no analytics you didn't ask for. Data flowing in a week, not a quarter.
Battery Supplier Qualification in a Box — fixed-fee engagement
One scoped engagement that delivers four things: a written cell acceptance spec, a test methodology that can prove or disprove it, an introduction to a partner lab that can execute, and a supplier-negotiation framework. It bundles twelve months of the data layer — your tenant is provisioned at kickoff and the lab ships results straight into it, so the qualification data accumulates in real time. Fixed fee, single PO.
These two paths are starting points, not destinations. As your test volume grows, your customer mix shifts, or a regulatory deadline lands, the data layer is already where it needs to be — and Micantis is already the team that knows your setup.
A last word
If you haven't gotten to this yet, that's not a competence problem — it's a sequencing one. You've been building drones, not running a battery lab; the two skill sets overlap less than the industry pretends. You don't need permission to start. You need a spec, a test plan, and a place to put the data that your own tools can reach. Micantis can help with the third, and point you at the right people for the first two. After that, the rest is yours to assemble — your tools, your models, your decisions, your data.