Learn Before You Spend: Prototyping Boom-Time's Action Sport Software

Boom-Time spent seven years building motion-capture hardware for action sports including mountain biking, skiing, motocross and similar. Before committing serious money to a software platform to use that data, the founder needed to see the product in action, use it under real circumstances, and find out which parts were hard. We built a deliberately throwaway prototype to answer those questions and practice working with early data collected from actual jumps.

A product with not enough data yet

Boom-Time uses a small tag attached to a mountain bike, a motocross bike, a ski boot etc., which talks to a mesh of ultra-wideband beacons on tripods set up around the track to record position, motion, acceleration and other parameters during jumps. They started with mountain biking and quickly discovered that other sports had an interest. The initial idea is to turn that into content: speed, height, airtime and G-force laid over the video of the run, for fans, broadcasters, athletes and sponsors. Building software to display metric overlays over a video is easy; the challenge was understanding the shape of the data coming from the main product - the hardware - and developing workflows and tools to work with it.

Our prototype worked beautifully with mountain bike and ski jump data, so these are the sports used in the rest of this story.

Useful outcomes before a solid spec

When David Bacon, Boom-Time founder, sent us his brief for the video overlay in April, it was clear about the goal: "Hero the action, and add value with simple data display. By the way, we are still figuring out the data."

After an initial discovery session with David it was clear how ambitious future plans were for the product in action sports and how big a market it opened. It was also clear how many things were not ready yet. After years of R&D and scientific research, the hardware worked, but the recording software was still in development, the data format was changing, and most importantly - there was no test footage. A typical agency would have waited for the client's spec to firm up, then quoted for a full build. For David that would mean months of waiting and expensive change requests, followed by a large bet on a design nobody had tried.

We did the opposite and built a baseline prototype with countless assumptions we knew would be challenged as we asked more questions and got more answers.

Separate what you know from what you don't

The one thing we knew for sure was that the overlay would show numbers on top of video. Everything else was open: which numbers, how they'd be computed, what the file would look like, how a person would line it all up.

So we split the problem in two. One half was presentation and user experience: how the overlay looks, what it shows, how someone uses it. The other half was data: reading whatever the kit produced and turning it into a clean timeline of position, speed and force. Keeping them apart meant we could iterate on how the product feels without waiting for the data, and swap the data layer out later without starting again.

It also meant building something small. The whole tool runs in the browser as long as data volume limits are respected. You drop in a video and a data file, select a synchronisation point (the tool offers some help), it draws the overlay on the video frame by frame, you adjust the presentation to fit your sport and brand, then export the result as a new video. Nothing is uploaded; the files never leave your laptop. There are no servers to run, no database (and no data to lose or compromise), no accounts. It runs locally or hosts on free tiers. That last point matters more than it sounds: a prototype that costs nothing to keep running is a prototype nobody feels pressure to turn off.

We built the tool so quickly, and worked so closely with David and his domain experts testing and adapting it, that it is functionally a well-tuned, sophisticated product. But technically and financially it is so obviously a throwaway prototype that there is no risk of it going live with technical debt because of the sunk cost fallacy - there is no sunk cost. The value is in the learnings.

Learning the data

The first real data arrived in May, from a test session with a member of the team riding. This is where most of the work went, and where most of the value was.

Raw sensor data is not a spreadsheet of answers. A few things we had to work out, with a lot of help from the hardware supplier's documentation and some patient physics tutoring:

• Time isn't a clock. The file doesn't carry timestamps you can read. Time has to be rebuilt from two counters the system increments as it records.
• Units aren't units. Speed comes in millimetres per second, the accelerometer in raw counts that need dividing to become G, the gyroscope in a different set of counts again.
• Height drifts. The vertical position wanders over a session, so an absolute height is meaningless. What you can trust is height relative to the take-off of the jump you're looking at.
• Some jumps looked far too long. On the very first pass, a few jumps came out with airtimes no rider could manage. That turned out not to be our maths but gaps in the recording, which told the team something about their capture setup they hadn't known.

That last one is the pattern we saw again and again. Putting the data in front of a working tool surfaced problems with the data itself, early, while they were still cheap to fix.

Finding the jump

The founder was worried, rightly, about one thing in particular. To show "jump height" and "airtime" you need to know exactly when a jump starts and ends, and he doubted an algorithm could find that reliably without a lot more data and development. He suggested a fallback: mark the jump roughly and let the person nudge the start and end by hand. His non-executive director suggested another: export the overlay as a transparent video and let whoever edits the film line it up on the landing impact.

Because the prototype was cheap to change, we didn't have to pick one on paper. We tried both and a few more. Finding jumps automatically turned out to be workable, and we learned that landings were a much easier point to sync data and video on.

Putting it in the founder's hands

In June I sent David the first rough version of the overlay on a test jump. I described it honestly: an exploration prototype, where everything (data, video, file format, interface) could still change, and which raised more questions than it answered (which I believe is a good thing).

His reply was:

A week later the tool was hosted and live, with an eleven-minute walkthrough video for the founder or anyone he wanted to use it, and one instruction: use it however you want, you cannot break it, give feedback. Because everything runs on his own machine and nothing is stored anywhere, there was nothing to break. That freed him to poke at it properly rather than tiptoe around it, as I often see clients do after sprint demos.

His non-executive director suggested a feedback method we'd recommend to anyone: record your screen while you use the tool, talk through what you're doing and what confuses you, and note the timestamps of anything that matters. It's far richer than a list of bullet points written afterwards.

What we learned

David went into the tool cold and found it understandable. He loved slow motion, which we'd added on a hunch. He struggled to line the data up with the video, which was worth the whole exercise: it told us where the product's real difficulty sits. It isn't drawing numbers on a screen, it's not cleansing data glitches - it's making the sync effortless for someone who isn't technical. That is now the problem to design around, and nobody spent a platform budget discovering it.

We learned a few other things too:

• An app, not a plugin. Generating the finished video directly means no video editing software in the loop, which changes who can use it and how it could be sold.
• Templates are the product. What the founder wanted next wasn't more settings but a library of ready-made looks, with configurable branded exports. In October we built the first version of this.
• Know when to stop. Every feature request edges a tool like this towards being a full video editor. Part of the job was saying where that line is.

Boom-Time also learned a lot about the hardware because there was software, albeit throwaway, to test against. In September the team ran a proper field test on a large road gap jump, with a rider who only repeated the jump three times because failure had real consequences. They came back with learnings:

• A new process for logging data and video so the two match up afterwards
• Gyroscope data drops out when a rider goes out of range of the beacons - a useful signal for trimming dead data

A purposefully very rough prototype

I want to be clear about what this tool is. It's a proof of concept, and a rough one. It has no accounts, no back end, and detection rules tuned on a handful of jumps. The data format underneath it will almost certainly change. It is not the platform.

What it did was answer the questions that would otherwise have been answered by an expensive build:

• What is the product, really? A tool that produces finished, branded video, not a data feed for editors.
• Where is it hard? Syncing, not drawing or data cleansing.
• What does the data need to be like? Captured with a matching process, with known drop-outs, read relative to the jump.
• What should we build next, and what should we leave out?

Next on David's list is something much larger: a full race-timing and analytics system, and the platform behind it. That is where the millions go. The difference now is that the specification can be written against real data, real footage and a real founder's reaction, rather than a pitch deck and a hope.

As he put it after trying the tool:

The lesson

You can learn a lot without making very expensive mistakes and fashionably "burning capital". The trick is to build the cheapest thing that puts a real decision in front of a real person, using real data, and to be honest that it's there to be thrown away. A prototype that answers "is this worth millions?" for the price of a few weeks' work over six months isn't a shortcut. It's the responsible way to start.

If you're sitting on an idea that would cost a fortune to build properly, and you're not yet sure which parts are hard, get in touch. We'd love to help you find out.