01
One system reviewed
Suspension, kinematics, springs, bars, dampers, brake system. Analysis, proposal, verification on track.
02 / Racing
Some teams call us to review the suspension, others to rebuild the team. Both requests come from the same place: the car is not doing what it should and nobody is sure why.
The point
The problem you were told about is almost never the problem.
"It understeers on entry" is a symptom. The cause can sit three systems away.
The first job is separating what the driver feels from what the car does. They are two different things and they have to be kept apart, otherwise you chase a sensation one component at a time and lose the season doing it.
That is why the way you come in does not constrain the analysis. If you call us about dampers we will still look at tyres, aerodynamics and weight distribution, because that is often where the answer is. And if the answer really was the dampers, we fix the dampers and stop there.
The second job is the team: who decides the set-up, on what data, and in how long. A structure that decides badly cancels out any engineering work, however correct.
Work
From the component to the programme.
In order of scale. You can move up and you can stop at the first level: both are legitimate endings.
02
Set-up and tyre window
Pressures, temperatures, degradation. Finding the real working window of the tyre you have, not the one in the datasheet.
03
Aero balance
Downforce, centre of pressure, ride sensitivity. The link between aero and mechanical grip is where the tenths go missing.
04
Race engineering
An engineer on the pit wall: run plan, decisions inside the session, debriefs that are worth having. Single event or season.
05
Rebuilding the team
Roles, procedures, decision chain, training. We look at how the team works, not only at how the car goes.
06
Full car development
The whole programme, with technical responsibility on us and targets agreed in writing.
How it runs
A race weekend with us.
Race engineering is the most requested line. It is worth saying what it actually involves.
Before
The run plan exists on Tuesday
Session targets, test order, criteria for stopping. Written down, shared, discussed with the driver.
Practice
You test what was in the plan
Free practice is not the moment for ideas: it is the moment you verify the ideas you had earlier.
Debrief
Feel and channels, kept apart
What the driver felt, what the data says, and where the two disagree. That gap is where the learning is.
Race
Decisions taken beforehand
On Sunday you execute. If strategy is still being decided on lap ten, the work was missing somewhere else.
After
What stays in writing
One document per event, which by the end of the year is your history. It is why you start ahead next season.
Engagement
How we agree terms.
| Model | When it makes sense | Commitment | What we deliver |
|---|---|---|---|
| Technical audit | There is a problem and nobody knows where it comes from | 2–4 weeks | Report with priorities and proposed work |
| Target project | The target is measurable: lap time, balance, tyre degradation | 3–6 months | Verified, documented changes |
| Race engineering | You need a reference engineer at the events | Event or season | Presence to calendar, one document per event |
| Technical responsibility | The programme needs leading, not just assisting | 12 months and beyond | Technical direction of the programme |
Questions
The usual ones, in writing.
Will you take a single job, with no season contract?
Yes, and it is the most common way to start. An audit on one system takes a few weeks and ends with a report: from there the team decides whether to go on or stop.
There is no obligation to continue. Half of these jobs end at the first intervention, and that is a normal outcome.
We already have a race engineer. Do we still need you?
It depends what is missing. If what is missing is someone at the events, no: you have that. If what is missing is development between events, or correlation with the simulator, then yes, and the two roles do not overlap.
We never come in to replace someone who is already doing their job. If that is the real problem, we say so to the team and decline the work.
Who decides the set-up in the end?
The team, except where technical responsibility has been given to us in writing. In every other model we propose, argue it with data, and the decision stays with you.
We insist on being clear about this before starting: ambiguity about roles gets expensive at the track.
Do you bring your own tools or use ours?
Yours, as a matter of principle. A method that only works with our software and our rigs is not transferable, and the benefit ends when we do.
If a tool is genuinely missing we say so and put it in the budget as an explicit line, not as a surprise.
First step
Let's start with one problem.
Car, category, what it does that it should not. That is enough for a serious first answer.