# What building a gelato app taught me about product work

> Balancing a gelato recipe, from PAC and POD to fats and solids, and optimising a conversion rate are the same craft: constraints, metrics and iterations. A CRO metaphor born from an app that was not supposed to teach me anything about work.

**Published:** March 5, 2026  
**Author:** Simone Bussoni

## TL;DR

I built Gelato AI as a hobby, but it reminded me of CRO rules better than many case studies. A gelato recipe is a system with constraints (PAC, POD, fats, solids) and traffic-light indicators: you change one variable at a time, measure and iterate. Like a conversion. The three lessons: define constraints before optimising, change one thing at a time, and decision signals are more useful than raw numbers.

---

Gelato AI was not supposed to teach me anything about work. It started as a hobby: I wanted to balance my own recipes without recalculating everything by hand. Then, while building it, I realised I was rewriting CRO rules with different words.

## A recipe is a system with constraints

Homemade gelato is not cooking, it is chemistry with cream. Every mix balances:

- **PAC**, anti-freezing power: how soft the gelato stays in the freezer.
- **POD**, perceived sweetness: how sweet it tastes, which is not the same as how much sugar it contains.
- **Fats and solids**, which define structure, creaminess and body.

Every variable pushes on the others. Add sugar for sweetness and you move PAC. Remove fat to make it lighter and you lose creaminess. There is no abstract perfect value. There is balance inside your constraints: your machine, your taste, your process.

Sounds familiar? It is a conversion funnel. Add information to increase trust and the page gets longer. Simplify the form and you lose qualification data. No lever is free.

## Lesson 1: define constraints before optimising

The first version of the app gave every recipe an absolute score. Useless: a perfect value for a professional batch freezer can be wrong for a Ninja CREAMi. I had to ask for the machine and skill level first, then calculate balance.

Work is identical. Optimising conversion without defining the context, such as traffic, product and margin, produces numbers that look right and decisions that are wrong. Constraints come before optimisation.

## Lesson 2: one variable at a time

When a mix did not work, the temptation was to fix three things at once. Wrong: if it works afterwards, you do not know why and you cannot repeat it. One change, one test, one reading.

That is A/B testing with a spoon. A test without a hypothesis is a lottery; a test with three variables at once is a lottery dressed as method.

## Lesson 3: signals beat raw numbers

The choice that made the app usable was not the calculation engine. It was the traffic lights. Green, yellow, red instead of "PAC 28.4". A raw number informs you; a signal helps you decide.

In work reports this lesson is often underestimated. A number that does not change a decision is furniture. The job is not producing more metrics, it is translating them into "what do I do now". A good report is a signal with sources attached.

## The moral

Balancing PAC and POD and optimising a conversion are the same craft: understand constraints, change one thing at a time, measure and translate the result into a decision. I learned it better from a gelato app than from several courses.

[Gelato AI is here, with the story behind it →](/en/lab/gelato-ai/)