How KASK cut their design cycle from a week to hours and tested 20× more.
How KASK went from 2 simulations a month to 60, same team, same budget, better helmets.
The bottleneck every helmet R&D team knows
Before AeroCloud, KASK’s aerodynamic testing workflow looked like this: prepare the geometry, send it to an external CFD consultancy, wait approximately one week, receive data, decide what to test next, and repeat.
In a single development programme, the team would start with 8 design concepts, narrow them to 2 or 3 aesthetic directions, and test 3 to 4 variants through simulation. That was the ceiling not because the team lacked ambition, but because each cycle cost a week of clock time.
On many projects the team was generating numerous design modifications, but not validating all of them. Simulation was being used primarily to confirm a direction already chosen, not to explore what else was possible. That one-week turnaround, multiplied across a development programme, meant the team was making decisions with less data than the product deserved.
In the end, you sometimes give up on doing another iteration, another attempt because time is running short and you can’t keep up. ~ Gerardo Lanfranchi, KASK product development team
The constraint was not the quality of the analysis. It was the structure of the process.
How KASK moved CFD in-house
KASK began transitioning to AeroCloud through a series of smaller projects starting with the aero visor where the team ran simulations directly rather than briefing an external party. Within less than a year, they had full in-house autonomy. Designers adopted the tool first. Engineers followed.
The ramp-up time was minimal. Once the geometry workflow was understood, launching a simulation required no specialist knowledge.
Once you understand how to handle the geometry and set things up, you just throw it in, run the calculations, and you can do whatever you want. From the point of launching a calculation, there isn’t much to learn. ~ Gerardo Lanfranchi, KASK
The numbers: before and after
| Before AeroCloud | After AeroCloud | |
|---|---|---|
| Simulation turnaround | ~1 week per cycle | Hours |
| Variants per programme | 3 to 4 | Open-ended |
| Simulations per month | 1 to 2 | 20 to 60 |
| Who runs simulations | External consultancy | Designers + engineers in-house |
| Team size for simulation | 2 designers + external | 2 designers + 1 dedicated analyst |
| Time to full autonomy | — | Less than 1 year |
What 60 simulations a month made possible for helmet development
The volume increase is not the story. What it changed commercially is.
Development cycles get cheaper. Moving from per-project consultancy fees to an in-house subscription changes the unit economics of testing entirely. The marginal cost of one more simulation run drops close to zero. Ideas stop being rationed.
More performance ends up in the product. With 20 to 60 simulations available per month, the team tests design directions they would previously have dropped. The solution space gets explored more thoroughly. The final product reflects the full range of what the team could test not just the narrow selection that the old constraints allowed.
Decisions improve earlier in the programme. When designers have aerodynamic data during the design phase rather than at the end of it, late-stage rework drops. Fewer surprises at production sign-off. The people proposing designs and the people validating them are now working from the same data at the same time.
Before, we probably weren’t making the best use of the money we were spending. Now we’ve optimised that. ~ Gerardo Lanfranchi, KASK
The numbers tell a clear story
A 10 to 20 times increase in simulation volume. Turnaround cut from a week to hours. A team that went from 2 designers dependent on an external consultant to a fully autonomous in-house capability all within less than a year of adoption.
But the more important shift is not in the numbers. It is in what those numbers made possible: a development process where more ideas get tested, decisions are made with better data, and the final product reflects the full range of what the team could explore, not just the narrow selection that the old constraints allowed.
If your development programme is still defined by strict and slow workflows and you are leaving tested performance on the table the question worth asking is not whether better testing is possible.
It is what your next helmet would look like if those constraints were not there.