Makros

Project

Makros runs a subscription meal-plan service. It delivers chef-cooked Mediterranean plans to the door, publishes a new menu every week, and bills its members on a recurring cycle.

This is a subscription business wearing a food business's clothes, and its economics read that way. They are decided by retention, not acquisition, because a subscriber who churns in week three never repays the cost of winning them. Retention in turn is decided by whether the menu published on the site is the menu the kitchen actually cooks.

That menu is a weekly operational artefact. Every cycle it is rewritten across several plan tracks, each with its own portion tiers and kcal bands, every meal carrying its macro split, all of it in Bulgarian and English. The inherited setup pulled it from a spreadsheet through plumbing that was both fragile and insecure. It was a single point of failure between the nutritionist and the Monday cycle, and it exposed a credential to anyone who looked.

We rebuilt the platform around that operating cycle. The spreadsheet sync is gone, and so is the credential it exposed. The test we designed to was operational, not technical: the client publishes next week's menu, in both languages, without contacting anyone.

We designed and built the Makros storefront along with the publishing and billing tools the weekly cycle runs on:

Weekly Menu Publishing: The client's own team puts each week's menu live: plan track, then portion tier, then day, then meal, laid out the way the kitchen already works, with kcal and macros carried at the meal. No developer sits inside the cycle.

One Bilingual Catalogue: Every plan track lives as a single record holding bilingual copy, weekly pricing and the full menu. Bulgarian and English publish from that one record, so there is no second version to keep in step.

Plan, Portion & Price Control: The commercial side is generated from the same record, so portion tier and billing period resolve directly to what the customer is charged. Pricing cannot disagree between the menu page and the checkout. That is the failure which produces refunds and support tickets rather than error logs.

Recurring Billing & Dunning: Weekly and monthly plans renew on their own, with a discount on the longer commitment. Renewals, cancellations and the dunning sequence on a declined card run on billing infrastructure that already handles them, instead of bespoke logic nobody wants to own.

Fallback Catalogue: If the source is unreachable, the storefront still serves plans and prices rather than an empty page. That protection matters most precisely when paid traffic is running.