The board's in fab.
We built what happens after it.

Nothing to power on, so we built forward

There is no board on the bench to bring up. Instead of sitting on our hands until it lands, we built the software that runs after a session ends: getting the data off the pod, onto a laptop, and eventually into the app a coach actually holds. None of it needed the real hardware to exist, so none of it waited on the fab.

Getting a session off a pod with no USB

V2 has no USB port. A session leaves the pod over Bluetooth or it does not leave at all, which makes the transfer layer the single thing the whole pilot rides on. If that is unreliable, nothing downstream matters, so it got built first and built against a development kit standing in for the pod.

The shape of it: a custom Bluetooth service that lists the sessions stored on the device and streams them off in chunks, picking up from where it left off if the phone drops mid-transfer instead of starting the whole thing over. The full recording stays on the pod's flash as the source of truth, and the pod never erases a session until the other side confirms it has a clean copy. Raw sensor counts go over the wire and get converted to real units later, which means a math mistake found in October is fixable across every session already collected instead of baked in forever.

A laptop that speaks the protocol

The next piece is a small program on a laptop that drives the whole transfer start to finish, no phone involved. Two reasons it comes before the app and not after. It is the reference the mobile app gets ported from, so every question the app will ever ask about the protocol gets answered first in the easiest place to debug. And it is the backup data path, so the pilot never depends on a first mobile app being the only way to get data off a pod. This company has already lost a generation of hardware to a single point of failure. We are not rebuilding that shape in software.

This one is mid-build, finishing in October.

The coach app

The app is where everything a coach or a parent touches actually lives. It is built iPhone first, dark the whole way through, and designed to work with the phone in airplane mode, because gym wifi is a rumor and the data has to be safe on the phone before anything tries to leave it. It runs the session, syncs the pods afterward, and turns that into one academy-branded page per kid that the coach reads, edits, and sends under his own name.

The screen during a session says almost nothing on purpose. A coach running eight kids is coaching, not watching a dashboard. The one thing it will interrupt him for is a pod that stopped recording, because finding that at minute 90 is finding it too late. The app is installable on TestFlight now, and every number in it is sample data, because the pods cannot feed it anything real yet.

None of it is real yet

We are not going to pretend otherwise. Every number in the app is placeholder data. Every byte the transfer moved was a test pattern on a dev board. The whole spine is built and proven against stand-ins, and that is genuinely the hard part behind us, but nothing about this product counts until a session comes off a real arm, through the pipeline, and lands as a score a coach reads and trusts. That is the next board, not this one.

What's next

• 01Finish the laptop host and have it drive a full transfer end to end on its own.
• 02Prove the transfer is exact: pull a session off flash over the debug probe, move the same one over Bluetooth, and compare them byte for byte.
• 03Get the sensor drivers running against a dev kit while the boards are still in the fab.
• 04Bring the real board up when it lands, power and radio before the sensors, and the optical front end last because it is the hardest.