MediaWiki success story for a local bakery
A fictional but realistic case study: using MediaWiki templates, forms and structured data to standardize recipes, track ingredient costs and cut training time.
Editor's note: this story is fictional — a realistic walk-through of how a small business can use MediaWiki, written to illustrate the pattern. All names and details are imaginary.
Sarah runs Crusty Crust Bakery, opened in 2018 with a grandmother's sourdough starter and a notebook-based knowledge system. Recipes lived in margins, ingredient costs in spreadsheets, supplier details on sticky notes. The low point came when an assistant baker used the wrong flour ratio in a signature recipe: 200 unusable pastries and a wedding client left without cinnamon rolls.
'We weren't managing knowledge, we were losing it,' she says. 'Every baker had their own version of every recipe. Training took weeks.'
The counterintuitive choice: a wiki
She evaluated cloud folders (mazes) and business software (too rigid for recipes that evolve seasonally). Her tech-minded nephew suggested MediaWiki — 'Wikipedia for a bakery.' The pitch: a page per recipe, editable by the bakers who actually know the process, with history so every change is traceable.
The wiki runs on MediaWiki with four extensions: Page Forms for data entry, Cargo for structured storage and queries, ParserFunctions for computation, and TemplateData for editor guidance. No custom code was written.
What was built
Standardized recipes. One template per recipe stores name, yield, timings, ingredients (as structured fields) and method. Page Forms turns it into a form, so a bakery assistant enters data without touching wikitext — the 'edit with form' tab hides the markup entirely. TemplateData gives VisualEditor a friendly dialog for quick adjustments.
Costing that computes itself. ParserFunctions calculates unit cost per recipe from ingredient prices kept in a Cargo table — the 'Ingredients' records track supplier, pack size and price per gram. A query displays cost per recipe, and when flour prices change, one edit updates every recipe that uses it.
Training on rails. New staff read the recipe pages (with photos and step notes), practice under supervision, and their first solo batches are logged on the talk pages. Sarah reviews edits via the watchlist — Echo notifications tell her when someone changes a recipe, which doubles as an early warning for 'creative' deviations.
History as a safety net. When a batch goes wrong, the recipe's revision history shows exactly what changed. The wedding-cinnamon-roll incident class of problem is now diagnosable in minutes.
The numbers after six months
- Training time for a new baker down from ~3 weeks to ~1 week (standardized, versioned recipes)
- Recipe-related batch failures: trackable, and down since the wiki — previously they were not measured at all
- Costing updates per month: minutes instead of an afternoon spreadsheet session
- One source of truth replacing notebooks, sticky notes and group chats
Why it worked
Three properties of MediaWiki made the difference for a non-technical team:
- Low-friction editing — forms and VisualEditor mean no one needs to learn wikitext to contribute
- Permission tiers — everyone reads recipes; only the head baker and Sarah edit them; the wiki enforces the hierarchy the notebooks could not
- Search and structure — CirrusSearch-quality lookup plus Cargo queries ('which products use almonds?') answer questions the sticky notes could only dodge
The bakery story is fictional, but the mechanics are not: templates for structure, forms for entry, queries for reporting, notifications for control. Those four pieces turn MediaWiki from an encyclopedia engine into a business knowledge system — no PHP development, no special hosting, just the extension stack a wiki already runs on.