Mokabon
- Client
- Mokabon
- Built with
- Shopify
- Timeframe
- 1 sprint
- Services
- UI/UX Design, Web development, Grow
A Ghent roaster since 1937, with a webshop that sold beans but skipped the craft. We rebuilt the product page around the brew itself: a live timer, a taste guide, and per coffee recipes Mokabon manages in Shopify without calling us. Built on their existing subscription app, rolled out product by product, zero new tools.
- Coffee is sold on taste and method, but the product page only showed a bag and a price.
- Every coffee has its own recipe: dose, water, grind size, brew time, pressure, temperature. None of that lived anywhere on the site.
- Putting recipes in the theme means a developer for every change. With 40 coffees, one roast profile update becomes 40 requests.
- They already ran subscriptions through Seal Subscriptions, but the offer was easy to miss on the product page.
- Rebuilding the existing product page would put 40 live products at risk at once.
A page built around what happens after the order arrives
Mokabon has been roasting coffee on the Donkersteeg in Ghent since 1937. Their webshop sold the beans, but not the craft behind them. We rebuilt the product page around the brewing itself: a brew guide with a live timer, a taste guide, and a live cafe block. No extra apps, no second subscription system, and no big bang.
01 Brew
A guide with a live timer
Filter and espresso each get their own tab. The recipe line comes straight from the product, and the timer counts through the pour steps with the water amounts calculated per coffee.
02 Taste
Four steps, one language
The taste guide is four steps, identical across the range and editable in the theme editor, so every coffee is described the same way.
03 Cafe
The shop, from the webshop
A live block shows whether the shop on the Donkersteeg is open right now, with today's closing time and a route button. The webshop and the physical store finally point at each other.
Everything Mokabon changes without asking anyone
Every brew value is a Shopify field, so a recipe change is an edit rather than a request.
A second product page, not a rebuilt one
The new template sits next to the existing one. Mokabon switches a product over one at a time, and switching back is one dropdown. Nothing is lost either way, and forty live products were never at risk together.
How we worked
- One sprint, one feedback round, fixed scope.
- Zero extra apps or subscriptions added to their stack.
- Nothing touched outside scope: prices, stock, existing product pages, checkout and emails were left exactly as they were.
- Handed over with two documents: a manual for operating the new page, and a written rationale for every change and every choice, in plain language.
40
Coffees in the range
11
New product fields
1
Sprint, fixed scope
0
Extra apps added
How we got there
The decisions that shaped this project, in the order we made them. Open one to see what it answered.
Rebuilding the live product page means one mistake hits 40 products at once. The new template sits beside the old one, so Mokabon decides per product when it moves over. If something behaves unexpectedly, switching the template back restores the old page instantly. Nothing is lost either way.
Recipes in the theme means a developer for every change. Now Mokabon changes a number in Shopify and it is live. Across forty coffees, that is the difference between one edit and forty requests every time a roast profile changes.
As free text, a field accepts anything: "28 s", "about half a minute", "1000 seconds". Turning them into numbers let us set limits, so brew time only accepts 15 to 60 and a typo is rejected before it reaches the site. The unit lives in the theme, which means switching "s" to "sec" is one edit for the whole range instead of forty.
Free text guarantees "medium fijn", "Medium-Fijn" and "MEDIUM FIJN" end up side by side on the same site. A dropdown makes that impossible, and filling products in goes faster.
A second subscription system means two places to manage subscribers, two kinds of billing and two things that can break. The new toggle sits on top of the existing app: the display is ours, the subscription logic stays theirs.
