APEXLAP

What happens when AI meets real expertise, instead of covering for the lack of it.

For months I had been using AI to build things I don't know how to build. It works — until you hit the edge of your own judgement and can't tell whether the machine is right or just confident.

So I turned it around. I pointed it at the one domain I know cold — sensors, embedded hardware, the messy physical world where signals are noisy and physics doesn't negotiate — to see what the same tools do in the hands of someone who can check their work.

72 hours later I had a GPS lap timer. Not a slide, not a demo — a functional proof of concept you can hold.

The build

The device is an ESP32-S3 running firmware in C, with a Quectel LC29D GNSS receiver reporting position at 10 Hz. On top of that sits a pure-C lap engine that learns the start/finish line on your first lap around a track, then times every lap after it against that line — no course setup, no app fiddling in a cold paddock.

The device talks to an iOS companion app over a custom BLE protocol we defined for this product: a compact wire format for live telemetry and session download. The on-device screen is built in LVGL, an embedded UI drawn in the same C the firmware runs.

It was built by a small team of specialist AI agents — hardware, firmware, app, and product — each an expert in its own lane, coordinated by a project-manager agent that owned the contracts between them: the BLE wire format, the data model, the interfaces where one agent's work meets another's. I reviewed, I steered, and I made the calls that mattered. The agents went deep; the judgement stayed human.

Four specialist agents — hardware, firmware, app, product — under a coordinating project-manager agent, with every call that mattered reviewed by a human.

The part I didn't expect

They didn't just build the features. They built the instrumentation that tells you whether the features actually work.

That distinction is the whole story, so let me be specific.

• The BLE wire protocol was implemented three independent times — in C on the device, in TypeScript in the app, and in Python for testing — and the three were cross-checked byte-for-byte against each other. A drift in any one implementation shows up immediately, before it ever reaches a track.
• The shared C UI compiles twice: once into the firmware, and once into a desktop simulator that renders every screen without any hardware attached. You can review the interface, and catch a layout bug, before a board exists.
• A BLE test oracle soaks the device at full 10 Hz live telemetry, then asserts p95 latency and returns a pass/fail exit code — the kind of result an agent can gate its own work on, rather than a human squinting at a log.
• Six iPhone simulators were booted, screenshotted, and vision-scanned for visual defects — the app checked by looking at it, not just by reading its state.

One BLE wire format, implemented three times — C, TypeScript, Python — and cross-checked byte-for-byte, so a drift in any one shows up before it reaches a track.

Work that used to cost me long evenings in a car park with a laptop on my knees, the agents turned into repeatable checks. Code is cheap now. Certainty is the expensive part — and this is where it gets made.

Where the honesty lives

GNSS reception underperformed. That is the interesting bit, not the embarrassing one.

We didn't guess. A diagnostic firmware build plus scripted, single-variable capture ruled out the processor, the power, the BLE radio, and the display — each one measured directly, not assumed away — and localised the deficit to the passive antenna and its ground plane.

Localised. Diagnosed. Not fixed. The antenna and ground-plane work is the next thing to test, and those tests are open. I'm telling you that on purpose: a diagnosis you can trust is worth more than a fix you can't, and the day a report stops distinguishing the two is the day it stops being useful.

That discipline is written into how the project runs. There is a validation gate: nothing counts as working until it has passed a closed-loop run on real hardware. The spec sheet carries numbers we have deliberately withheld — positional accuracy, battery life, and the rest stay blank until the specific test that earns each one has actually been run. Not caution for its own sake. Just refusing to publish a number we haven't measured.

What it actually does

Underneath the story is a real product. APEXLAP is a standalone GPS lap timer and datalogger: it works on its own at the track, and no phone is required to record.

On the device, it detects the start/finish line automatically and lets you mark laps by hand when there's no fix yet or you're indoors. It runs acceleration and brake-test modes for sprint, drag and stopping runs. And it records every run as a complete session — lap times plus continuous 10 Hz GPS and IMU telemetry — and keeps recording even without a GPS fix, so motion and timing survive a dropout. Past sessions are browsable as lap history right on the screen.

Pair the iOS app over Bluetooth and the session comes down to the phone: a satellite track map with each lap drawn as its own trace, and insights that turn the log into something you can act on — best-lap trend, personal bests, and lap-to-lap consistency. Telemetry backfill recovers fixes and laps captured while out of Bluetooth range, and sessions export to CSV.

What we can stand behind

Every number here has been measured or verified in engineering; nothing is projected.

• Compute — ESP32-S3, 8 MB PSRAM, 16 MB flash.
• Display — 1.91" AMOLED, 536 × 240, capacitive touch.
• GNSS — Quectel LC29D, 10 Hz, dual-band L1/L5, multi-constellation (GPS / GLONASS / Galileo / BeiDou / QZSS / NavIC).
• Lap timing — recorded to 0.001 s, typical AUTO GPS lap repeatability ±0.05 s; cold-start fix ~30 s typical, under 45 s (measured).
• Motion — QMI8658 6-axis IMU, ±16 g / ±1024 °/s (g reported as magnitude).
• Storage — microSD plus internal flash; sessions kept on-device.
• Connectivity — Bluetooth LE, secure bonded pairing.
• Firmware — over-the-air updates over BLE, SHA-256 verified.
• Export — CSV.

And the part I'm most sure of is what isn't on that list. There's no positional accuracy in metres, no battery runtime, no enclosure size or IP rating — not because the answers are unflattering, but because we haven't yet run the specific test that earns each one, so no number goes on the page. The blanks are deliberate, and they're the same discipline as the GNSS section made concrete: a spec appears here only after the measurement that backs it, and not one line sooner.

APEXLAP is currently in development.

AI in the right hands amplifies your habits and your abilities. If you're about process and craft, you become a super builder. If you're not, it just helps you ship the wrong thing faster.

Polystage builds hardware and embedded systems, AI systems that do real engineering work, and provides fractional-CTO leadership for teams taking something hard from prototype toward production.

If any of that is a problem you're carrying, start a conversation — a short technical exchange, no pitch.