In independent cafés and beverage-led businesses, new drinks usually start the same way:
with an idea that feels reasonable.
It might be seasonal.
It might be something customers have mentioned.
It might simply feel like time for a change.
Once that decision is made, things move quickly. Ingredients are ordered, recipes are tested, staff are briefed, and the menu is adjusted. By the time the drink is live, a fair amount of time, money, and attention has already been committed.
What we kept noticing is that problems rarely appeared at the idea stage.
They appeared later.
Preparation took longer than expected.
Service slowed down at busy hours.
The drink only worked smoothly with certain staff on shift.
Small changes introduced more complexity than the menu could absorb.
By then, the decision wasn’t really reversible.
Most tools in this space focus on what happens after a product exists: pricing, margins, trends, performance. Those are useful questions — but they assume the drink should already be on the menu.
What was missing was a simpler decision, made earlier:
Should this idea be developed at all?
Not in terms of taste or popularity, but in terms of whether it fits the operation that has to deliver it, day after day.
As we looked more closely, a pattern became clear.
When drinks were removed or quietly phased out, it was rarely because customers disliked them.
They failed because of operational friction:
too many steps, too many ingredients, too much variation, too much strain at peak service.
These aren’t things that show up in a recipe test.
They show up in real service.
And once they show up, the cost has already been paid.
This is where the idea of a pre-development decision came from.
A deliberate checkpoint before development begins — before ingredients are purchased and workflows are changed — that asks whether an idea stays within what an operation can realistically handle.
It doesn’t try to predict demand.
It doesn’t try to optimise flavour.
It simply answers a more basic question:
is this viable in this context, with these constraints?
If not, the most practical outcome may be to decide not to build it.
That decision layer is what MakeOrNot is built around.
The aim isn’t to reduce creativity or experimentation, but to make sure those efforts are spent on ideas that have a chance of working in the real world.
Because in small teams and busy kitchens,
every decision carries weight — especially the ones made before anything is built.