Skip to contentENES
Kocin landing page: the headline about clear recipes and clear numbers next to a photo of a lemon cake, with the card showing the recipe's estimated cost.
Back home

Kocin

A recipe book with estimated costing for professional kitchens, where proportions cannot be improvised.

Role
Product and development — from idea to MVP
Year
2026
Stack
Next.js · TypeScript · Supabase · Prisma · PostgreSQL
In progress
Visit live ↗

Where it came from

It came out of a conversation with someone working in the pastry section of a restaurant. The problem was not technical: the team’s knowledge lived on loose sheets and got shared as photos.

The brief

The scope is deliberately narrow: ingredients are added once and recipes are built on top of them, with exact quantities and ordered steps. Nothing more is needed to solve the problem that started it.

The one decision that adds something is giving ingredients a price: that turns the recipe book into a cost estimation tool at almost no extra cost. For now it is deliberately an estimate; turning it into strict cost control is v2, not the MVP.

The method

I built it working with AI agents on spec-driven development: I wrote the specs, set the architecture and reviewed the result across several passes, with tests and CI running lint, test and build.

How it is going

It is in development and close to launch. What I take away is that the small scope was the right call: the problem was so well defined by the person living it that the temptation was to add things nobody had asked for.

Problems and solutions

01

Problem

The pastry section's recipes lived on paper. Sharing them with colleagues meant having that paper at hand, or sending a photo over WhatsApp. If the paper is lost, the recipe is lost: even if they know how to recreate it, it takes work, and doing so shifts proportions without anyone noticing. In pastry that is not a detail, it ruins the result.

Solution

A shared recipe book where each recipe is built from stored ingredients, with exact quantities and an ordered list of steps. It stops depending on a sheet of paper and on somebody transcribing it correctly.

02

Problem

Nobody knew what a recipe actually cost, so pricing what got sold was guesswork.

Solution

Each ingredient stores its price and purchase quantity. When building the recipe you state how much of each is used, and from that comes the cost of every item and the batch’s estimated total, alongside the yield in portions. Pricing stops being guesswork: there is a number to argue with.

Gallery

  1. The full recipe book: 21 recipes with their photo, their steps and ingredients and the estimated cost of each, over a pantry of 64 ingredients that all carry a price.View full size ↗
    01The full recipe book: 21 recipes with their photo, their steps and ingredients and the estimated cost of each, over a pantry of 64 ingredients that all carry a price.
  2. A recipe open: the yield in portions, the six ingredients with their exact quantity and what each one costs, and the batch total estimated at 6,765 pesos.View full size ↗
    02A recipe open: the yield in portions, the six ingredients with their exact quantity and what each one costs, and the batch total estimated at 6,765 pesos.
  3. An ingredient's detail: the purchase unit and price behind its unit cost — sugar, one kilo at 1,500 pesos — which then feeds the cost of every recipe.View full size ↗
    03An ingredient's detail: the purchase unit and price behind its unit cost — sugar, one kilo at 1,500 pesos — which then feeds the cost of every recipe.

0103