People Don’t Want More Data. They Want to Know What to Pick.

KnowDish has a slightly ridiculous amount of meal data in it now.

Prices, calories, protein, ingredients, dietary tags, delivery formats, service types, and hundreds of individual meals across different providers.

For a while, I thought the main job was to make all of that easier to compare.

It turns out that isn’t quite the problem.

Most people do not arrive thinking:

I would like to inspect the nutritional and commercial characteristics of 900 prepared meals.

They arrive thinking something more like:

I’m busy. I don’t want takeaway every night. I want to eat reasonably well. Which one of these services should I actually choose?

That is a very different product problem.

Comparison is not the same as decision-making

A comparison product can technically be excellent and still be exhausting to use.

You can add more filters, more columns, more charts and more data points. You can expose every difference between every provider.

And somehow make the decision harder.

This is not especially surprising from a behavioural science perspective. More information does not automatically create more clarity. It can increase cognitive load, make trade-offs harder to evaluate and encourage people to focus on whatever happens to be easiest to compare rather than what actually matters to them.

• Price is easy to compare.
• Protein is easy to compare.
• Calories are easy to compare.

“How likely am I to actually stick with this service for the next three months?” is much harder,

but that's probably closer to what matters.

Users often don’t know their criteria yet

This became one of the more interesting things about building KnowDish.

A normal filtering interface assumes that users already understand what they are looking for.

"Choose your calorie range."

"Choose your protein target."

"Choose fresh or frozen."

"Choose your budget."

"Choose your dietary preferences."

Then we show you the matching options.

That works well if someone arrives with clear criteria.

But a lot of people do not.

They know the outcome they want before they know the attributes that produce it.

“I want to eat healthier.”

“I want something convenient after work.”

“I’m trying to lose weight.”

“I need more protein.”

“I’m buying for two people.”

“I don’t want meals that feel like diet food.”

These are not database filters. They are intentions.

The product has to translate those intentions into something a dataset can actually reason about.

That is why I became more interested in the step before comparison.

Before asking someone to choose a protein threshold, perhaps the better question is whether they train regularly, what they are trying to achieve, how often they expect to use the service and who else they are feeding.

The user should not have to understand the structure of the database in order to use the product properly.

The product should do some of that work for them.

Not every difference is useful

Another thing I underestimated is how easy it is to surface differences that are technically true but practically meaningless.

If Service A averages 38g of protein and Service B averages 41g, is that an important difference?

Maybe.

Maybe not.

If one is significantly cheaper, has meals the user actually wants to eat and delivers on the days they need, the three grams probably do not matter very much.

This sounds obvious when written down.

It becomes less obvious when you have a database full of measurable attributes and a charting library.

There is a strong temptation to show everything simply because you can.

A lot of product work, I’m learning, is deciding what not to make the user think about.

“Healthy” is an especially unhelpful word

Meal-prep services are full of broad claims.

Healthy.

Balanced.

High protein.

Clean.

Nutritious.

Performance-focused.

The words are useful for marketing because they are flexible.

They are much less useful for comparison.

“Healthy” might mean low calorie to one person, minimally processed to another, high protein to someone training five times a week, or simply better than ordering Deliveroo every evening.

So rather than deciding whether a meal is “healthy”, I would rather show the evidence underneath the claim.

How much protein does it contain?

What is the calorie range?

What ingredients are used?

What does it cost?

Is it fresh or frozen?

How large is the menu?

What information does the provider publish, and what do they leave unclear?

That still leaves the final judgment with the person making the decision.

Which is where I think it belongs.

The ranking problem is the interesting part

Once you start helping people choose rather than merely compare, another problem appears.

Ranking requires judgment.

There is no objectively “best” meal-prep service.

There is only best given a particular set of preferences and constraints.

A cheaper provider might rank higher for one person.

A service with higher-protein meals might rank higher for someone else.

A household may need a provider that accommodates two completely different goals.

Someone who hates freezing meals may reject the option that looks strongest on every nutritional metric.

So the interesting question becomes:

How do you make the judgment explicit enough that the user can understand why something is being recommended?

That matters even more once AI enters the product.

It would be easy to build a recommendation layer that confidently announces:

This is the best service for you.

I am much more interested in something that says:

Based on what you told us, these three look like the strongest fit. This one ranks highest because you prioritised protein and price. This one scores slightly lower because its meals are more expensive, but it has a larger menu.

That is less magical but much more useful.

Good decision tools reduce translation work

I think this is the part of KnowDish I find most interesting now.

It started as a comparison site.

But increasingly I think of it as a translation layer.

Providers describe themselves using marketing language.

Databases describe them using structured attributes.

Users describe what they want using vague goals, habits and constraints.

Those three languages are not the same.

A useful product has to translate between them without pretending that the answer is more objective than it really is.

That means collecting good data, but it also means knowing where the data stops helping.

It means designing filters, but not assuming people arrive knowing which ones to use.

It means ranking options, but showing why.

And it means resisting the urge to turn every measurable difference into something the user has to care about.

The goal is not to help someone understand every meal-prep service.

It is to help them reach a decision they feel comfortable making.

That is a much smaller output.

And a much harder product to build.