MasAsk

Vendors view of what orders they had.
Vendor's shop settings.
Your cooking groups, where you and you friends can cook your mystery dishes! You can join up to three groups at the same time.
Vendors view of what items that they already had.
List of menu collections that you already unlocked when you cooks.
Your inventory/fridge, containing whats item that you currently have right now.
Selecting what ingredients that you already have.
The "Patungan" or split bill system, where you can share expenses with your friends.
The market where you can buys items for your next cooking session

Inspiration

Then we read Bappenas' food loss study. 62.8% of Indonesia's vegetable supply is lost. We throw away more vegetables than we eat. But their third-biggest cause isn't infrastructure at all: "bahan yang tidak lazim tidak dibeli sehingga akhirnya terbuang". Unfamiliar ingredients don't get bought, so they rot.

What it does

MasAsk gathers ingredients & tools that you (and your friends) already have, and currently surplus ingredients. It then would return you a single mystery menu.

You see the ingredients, steps and tools, while you guess what you're cooking. You only pay for what you don't already have. And because you never picked the vegetable, "unfamiliar" stops being a reason not to buy it.

Then the part that matters to the farmer: everyone's orders aggregate. Scattered purchases become one confirmed number he can harvest against. Harvest Friday, pickup Saturday morning, cook Saturday noon so freshness comes from scheduling, not refrigeration.

How we built it

At first, I gather the required data, doing some tokenisations, and map the data relations into a vector database. After that, we just connect all the stuffs since actually the system isn't that complex, basically a big parsed data that connected, filtered based on needs & priorities.

Challenges we ran into

The data killed our thesis. We originally pitched that waste comes from oversupply. It isn't in Bappenas' top five causes. We could've kept the story and hoped nobody checked, instead we rebuilt the framing around the cause we actually address.

An architecture conflict we found late. We designed dish selection to filter by surplus and rank by your pantry. But aggregation needs many people on the same dish, and personalised selection gives you 200 cohorts of one, with no aggregation meanings no real farmer benefit. We split it: dish is per-cohort and surplus-driven, pantry only subtracts from the box. Simpler than what we'd planned.

Accomplishments that we're proud of

The loop closes. Vendor declares surplus -> it becomes the mystery dish -> people order -> the orders aggregate into a number the vendor harvests against.
Freshness without a cold chain. We can't build refrigeration in 30 hours. We didn't need to. We deleted the wait instead.

What we learned

Time management and basically how's we can solve a problems that looks so tech-y (distribution problems, that usually solved with better cold chain system), with alternative, yet more plausible solutions on a small scale.

What's next for MasAsk

The real flywheel is feeding aggregated demand back to farmers as a planting signal. attacking the "pola tanam seragam" that causes the glut.
Pantry decay. Today we only skip staples we know you own. Next is retuning the algorithm by shelf life and time since purchase, so the recipe algorithm would fit the users' current, already ingredients better.