Because the load cannot see a gap. Handing supply from one pack to the next while equipment is running turns a convenience feature into the system's core mechanic, and the BMS, protection circuitry, and voltage regulation all exist to make that handover safe rather than merely possible.
Case study
The equipment cannot stop. Everything else follows from that.
2022–2025 · EDSPTech · Technology advisor and seed investor · Public. Product architecture for a connected battery system where the hardest requirement was continuity.
What it was
A modular battery and charging system for mobile medical equipment — the carts and trolleys that move between rooms and have to keep working while they move.
| Battery | 36 V, 680 Wh |
| Charging stations | one-, two-, and four-battery |
| Power management | smart BMS with protection |
| Swap behaviour | hot-swap |
| Outputs | 3–70 V, plus USB-C |
| Connectivity | Wi-Fi with cloud monitoring |
Read that table as a set of independent features and it looks like a competent power product. Read it as one system and a single requirement is doing all the work.
The constraint that shaped everything
Medical equipment on a cart cannot lose power because a battery reached the end of its charge.
That one sentence is what makes this a hard product rather than a straightforward one. Hot-swap stops being a convenience feature and becomes the core mechanic: power has to be handed from one pack to the next without the load ever seeing a gap. Everything above — the BMS, the protection, the multiple voltage rails — exists to make that handover safe rather than merely possible.
The 3–70 V output range compounds it. One pack feeds devices with different power requirements, so the system regulates across a wide range while a swap is happening underneath, and while the whole thing reports its own state over Wi-Fi.
Where hardware meets software
This is the boundary the project lived on, and it is the reason the work was architecture rather than engineering management.
The BMS is a hardware safety system with hard real-time obligations: cell protection, thermal limits, current control, and the swap sequence itself. None of that can wait on a network. The monitoring layer is the opposite kind of system: Wi-Fi, cloud, dashboards, fleet visibility, firmware updates — all of it best-effort, all of it allowed to be late or absent.
A connected battery is where those two disciplines meet in one enclosure. Get the line wrong in the direction of the cloud, and a network problem becomes a safety problem. Get it wrong in the other direction, and the product is a dumb battery with a radio glued on.
Drawing that line — what the device decides alone, what it merely reports, and what it will accept from outside — was the design decision the rest of the roadmap hung off.
What the engagement was
Technology advisor and seed investor at EDSPTech, January 2022 to January 2025.
The work was product architecture across the battery, the charging stations, and the monitoring layer; holding the hardware/software boundary as the product grew; shaping the technology roadmap; and supporting engineering hiring — because a product on this boundary needs people who are comfortable on both sides of it, and those people are scarce.
What this case shows
| Claim | Evidence |
|---|---|
| The product is real and specified | 36 V / 680 Wh packs, 1/2/4-bay stations, BMS with protection, hot-swap, 3–70 V and USB-C outputs, Wi-Fi and cloud monitoring |
| The requirement, not the feature list, drove the design | continuity of supply to running medical equipment |
| The engagement was architectural | advisor across product architecture, hardware/software boundary, roadmap, and hiring, 2022–2025 |
What it does not claim
- No deployment numbers. Units built, sites, or installed base are not published here because they are not independently established.
- No funding claim. A round is understood to have closed during this period, but the amount and investors are not publicly confirmed, so nothing is asserted about them.
- No measured reliability outcome. This is a description of what was designed and why, not a report of field performance.
The case is worth publishing as an engineering problem. It is not worth dressing as a results story it cannot support.
FAQ
Frequently asked questions
36 V, 680 Wh battery packs; charging stations in one-, two-, and four-battery configurations; a smart BMS with protection; hot-swap; outputs from 3 to 70 V plus USB-C; and Wi-Fi connectivity with cloud monitoring.
Safety decisions belong to the device and must never wait on a network — cell protection, thermal limits, current control, and the swap sequence. The cloud gets visibility, fleet state, and updates. Moving a safety decision across that line turns a connectivity failure into a safety failure.
Technology advisor and seed investor at EDSPTech from January 2022 to January 2025: product architecture across battery, stations, and monitoring; ownership of the hardware/software boundary; the technology roadmap; and engineering hiring.
Not published. Deployment figures for this product are not independently established, so this case describes the design and its constraints rather than claiming a field outcome.
Prefer a conversation first?
If you would rather talk it through before sending a brief, book a short routing call and we will point you to the right next step.