Where CoffeeJSON fits

One document — a title, a dose, a pour schedule, the bean. Here is what it does once you have it.

• Between two apps

  Someone leaves your app with two years of brews and comes back later with more. You write one importer instead of one per vendor whose share codes you reverse-engineered yourself.

• On a bag of coffee

  Print a QR on the bag. Your customer scans it in their kitchen and their phone walks them through your method — your dose, your grind, your pours. No app to build, no account for them to make, no link that expires.

• In a link

  Paste a recipe into a message and it arrives whole. The document rides inside the URL, so nothing is stored and nothing is looked up — and it still opens after whoever hosted it is gone.

• On a web page

  Publish your method as data instead of a picture of a table. A reader can send it straight to their timer, and it exports to schema.org Recipe, so search engines read the actual steps. A bag exports the same way, as a Product whose identity is the coffee's — never its price.

• In files you keep

  Your brew log is plain .json on your own disk. When an app shuts down or changes its pricing, you already have everything — no export deadline, nothing to rescue.

Four of these run on this site today. The bag is the one nobody has shipped — its transport is specified and working.

What has shipped

• 

  BrewSmart

  iOS · watchOS

  Opens share links, and publishes share links.

The first implementer, and so far the only one. Shipped it? Add yourself to the registry — no approval step.

Implementing it

More implementations are the whole point, and there is help getting there: ask, and the importer and exporter get written for you — tested, with an example, yours under Apache-2.0 either way. Feedback counts as much as adoption: tell us what the format gets wrong and it changes.