Motorsport Team Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope spread from a few components to the entire parts list?

Every one of these projects starts with the same sensible sentence. We need to track gearboxes and engines properly. Two weeks later somebody in design asks whether uprights should be in there, because they are life limited too. Then dampers, because they go away for rebuild. Then the machine shop wants work orders in the same place, because it is silly to have two systems. By the time the scope is written you are building a manufacturing platform rather than a lifing system, and the first release date has moved from twelve weeks to nine months.

It happens here specifically because almost everything on a racing car has some claim to being tracked. There is no natural boundary the way there is in a factory, where regulated items are a clearly separated subset. In racing the boundary has to be drawn on purpose, by someone senior, and written down.

The fix is to scope the first release to component families that carry either a regulated allocation or a mandated inspection interval. That is usually a small share of the parts list and the overwhelming majority of the risk, and it keeps the release inside the 12 to 18 weeks the honest estimate assumes. Everything else, including the machine shop, is a later phase that is far cheaper once the serialised model exists and has proved itself over a race weekend.

What goes wrong when you load the life positions of the components you already own?

The technical import is a day of work. The reconciliation is the project. Loading opening positions means physically walking the racks, reading serial numbers off components and comparing them against a spreadsheet that has been maintained by three different people across two seasons. Every team we have done this with has found discrepancies: units on the sheet that were scrapped, units in the building that are not on the sheet at all, and mileage figures that were last updated before a rebuild.

The trap is trying to reconstruct history. Somebody proposes backfilling two seasons of session data so the accrual looks complete, and the project spends six weeks producing numbers that are still estimates because the build sheets from last May do not exist in a usable form.

The fix is to declare an opening position and sign it. Each serialised item enters the system with a stated life at a stated date, agreed by the chief mechanic and the team manager, recorded as an opening balance rather than as calculated history. From that moment accrual is automatic and defensible. Teams routinely tell us afterwards that the physical audit was worth the build fee on its own, because it found components nobody could account for.

Why do the car data and procurement integrations break after launch?

Two integrations matter here and both fail in the same predictable way. The first is the car's logging data, which supplies distance and running time so life accrues without anyone typing. That feed changes. A new logger, a new export format between seasons, a channel renamed by a data engineer who had no idea anything downstream depended on it, and suddenly a whole test day accrues nothing. Nobody notices for a fortnight because the system does not complain about silence.

The second is procurement. If you make parts in house, the serial identity used by the machine shop and the serial identity stamped on the component in the rack have to be the same string, and they usually are not. One system pads with zeroes, the other does not, and the join quietly produces duplicates.

The fixes are unglamorous. Make the ingestion loud: if a session is logged in the timing sheet but no accrual arrived, that is an alert, not a gap. Keep a manual accrual path for one session so a broken feed never stops the weekend. And settle serial identity in one place at the start, with a single authority for issuing numbers, rather than letting two systems each believe they own the format.

What happens when allocation rules and inspection blocks are not covered?

Allocations get left out of first releases more often than anything else, because they feel like reporting rather than operations. They are not. The allocation position is the sporting consequence of a technical decision, and if it lives in a separate tracker maintained by one person in operations, it is only correct on the days that person is asked.

The failure is specific and it is late. A component is changed on a Friday for a good engineering reason. Nobody realises it moved the team to the limit. In September a further change becomes necessary, the penalty applies, and the conversation afterwards is about who should have known.

Inspection is the same shape with a worse ending. If a crack test result lives in a folder rather than attached to the serialised item, the inspection policy is advisory. It only becomes a control when a failed or overdue inspection blocks fitment in the software the mechanic is using at the point of work.

The fix is to hold allocation rules as dated, versioned policy attached to the serialised records, so the pool position is current at all times, and to make inspection status a hard gate on fitment rather than a field. Scenario modelling follows naturally: given the remaining calendar and expected mileage, which race is the cheapest place to take a penalty you already know is coming.

Should you build custom or configure what you already own?

Some readers should not build, and this is the honest boundary. If you run a small programme on a national calendar, with no regulated allocations, a handful of life limited components and one person who genuinely knows where everything is, a disciplined spreadsheet is the correct system and the money belongs in the car. That is a real situation and we have said so on calls.

The middle option is worth taking seriously too. Most teams that manufacture parts already run an enterprise resource planning (ERP) system for procurement and the machine shop, and systems in that class, NetSuite and Sage among them, carry serial and lot tracking of some form. If your requirement is knowing which serial you own and where it is, configure what you have before commissioning anything. It will not model dated assembly membership or apportion session mileage through a build sheet, and that limit is exactly where the build case begins, but plenty of teams discover they needed the inventory discipline rather than the lifing engine.

Build when the sporting or safety consequence is real: regulated allocations that cost grid positions, more than two cars or more than one championship sharing inventory, flyaway events with sea freight kits, or a weekend where nobody could state how much life a fitted component had.

How do hidden costs get into the quote?

Five things move the number in this category and none of them appear in an early scope document. The number of championships you contest is the largest, because each brings its own regulations, its own allocation model and its own report formats, and a second series is not a copy of the first.

Offline capability is the second, and it is regularly quoted as a later phase by developers who have never worked in a garage. Connectivity at a circuit is unreliable and the work does not stop when it drops, so full offline capture with conflict safe synchronisation is a first release requirement. Retrofitting it costs far more than building it in, because it changes how every write is designed.

The third is car data integration, which is straightforward when logging exports are accessible and awkward when they are locked inside a supplier system. Ask for that access before signing. Fourth is the number of component families, since each carries its own life measures and inspection regime. Fifth is confidentiality: component life and reliability data exposes your development position, so hosting, access control and end of relationship terms are real work rather than boilerplate. Agree them before kickoff rather than in month four.

What separates a build that works from one that fails here?

Capture at the point of work is the single strongest predictor. A mechanic finishing at one in the morning will scan a tag on a phone or a rugged tablet and sign for it. They will not open a laptop and complete a form, and a system that requires them to will be bypassed within two weeks, after which every downstream number is fiction.

The second is the data model. Ask any developer to draw it in front of you before they quote. A capable team draws serialised item, specification state, assembly membership with date ranges, life accrual event, inspection record and allocation pool, and they identify parts moving between assemblies as the hard part. A team that draws parts and stock levels has built a warehouse system and it will not survive a gearbox rebuild.

The third is that the record is append only with attributed corrections. If a mileage figure can be edited quietly, the history is worth very little in an investigation. The fourth is ownership. You should hold the repository, the database and the cloud accounts from the first commit, with the unrestricted right to hire someone else, because regulations change between seasons and you cannot be waiting on a supplier relationship to update a rule before the next round.