That Point Is Exactly Where the Money Is.
I have spent most of my career in food labs. I know what it looks like when a development process is working, and I know what it looks like when it is not.
Here is something I have noticed: the projects that fail or overrun are almost never the simple ones. A seasoning adjustment, a starch swap, a minor label change. Experienced technologists handle these without drama. Traditional R&D was essentially built for this kind of work, and it does it well.
The projects that struggle are the ones that matter most commercially. Novel protein systems. Clean-label reformulations that cannot sacrifice texture or shelf life. Products that need to land on taste, nutrition, cost, and regulatory compliance simultaneously. These are not incrementally harder. They are categorically harder.
Why complexity multiplies, not adds
Food formulation involves hundreds of interacting variables. A skilled technologist can intuitively hold perhaps a dozen in mind at once. When you add variables, you do not add complexity linearly. You multiply it. And the cognitive tools that work at low complexity start to fail at high complexity: anchoring bias, fatigue, the tendency to stop questioning early decisions after four or five rounds of iteration.
I have watched good teams get stuck not because of a lack of skill or effort, but because the problem outgrew the mechanism they were using to solve it.

How the gap compounds, iteration by iteration
The difference is not most visible at the start of a project. It widens at every subsequent step.
| Iteration 1: The starting pointTraditional R&D begins with experience and intuition. The first-round prototypes depend on whoever prepared the brief and whatever knowledge they happen to hold. When a technologist is unfamiliar with a product category, the research phase alone can add days or weeks before a single prototype is made. That time is unstructured, unrepeatable, and entirely dependent on who happens to be in the room. |
| Iteration 2: Integrating sensory and analytical dataA human technologist reviews tasting notes and lab results and draws conclusions limited by their own cognitive bandwidth and existing assumptions. An AI-supported process ingests the same data and connects it across all variables simultaneously: ingredient interactions, process conditions, texture-flavour relationships. It identifies patterns a human would miss, or would take weeks to triangulate. The second batch is not just refined. It is directionally smarter. |
| Iteration 3: Applying the knowledge libraryThis is where the gap widens significantly. Proprietary formulation insights, ingredient supplier data, and category-specific benchmarks can be applied directly to the next round. Traditional R&D has no equivalent mechanism. That kind of knowledge lives in people’s heads or scattered documents, and applying it consistently across a team is practically impossible. |
| Iteration 4: Drawing on adjacent projectsIn traditional R&D, learnings from a previous project rarely inform the next one in any structured way. They are filed, forgotten, and rediscovered by accident. An AI-supported process can explicitly draw on adjacent projects: pulling proven formulation logic, documented failure patterns, and successful ingredient combinations from related work. Every past project becomes an active asset rather than a forgotten file. |

The knowledge problem underneath
There is also a compounding problem that sits underneath all of this. Insights from one project rarely transfer cleanly to the next. They live in someone’s head, or in a lab notebook that nobody reads. Each project largely starts from zero. The institution does not get smarter over time the way it should.
Two technologists given the same brief will produce different results. Not because one is better, but because the process is subjective by design. There is no reproducibility, and no systematic way to audit why a particular direction was chosen.
The core argument
This is the problem we set out to address at AKA Foods when we built AKA Studio. Not to replace food scientists, but to give them a tool that does not degrade as the problem grows harder: one that connects sensory, analytical, and formulation data across all variables simultaneously, that makes institutional knowledge permanent and searchable, and that brings learning from adjacent projects into each new brief as a matter of course.
The efficiency gains on simple projects are real. But efficiency was never the core argument. The core argument is capability: for the projects where it matters most, the gap between what a traditional process can achieve and what a well-supported one can achieve is not a matter of weeks. It is the difference between arriving at a genuinely optimised product and settling for the best your team could manage under the constraints of the process you were using.
The more complex the project, the wider that gap.