Building a CMS for Self-Service Kiosks: Empowering Clients at Scale

Introduction: The Customization Problem

Every restaurant chain wanted the same thing: a kiosk that looked like their brand, flowed like their process, and changed as fast as their menu. Burger King wanted loyalty points integration. Quick wanted seasonal menu automation. Independent chains wanted regional customization per location. Every request meant dev work, QA testing, deployment cycles—2-3 weeks minimum.

The bottleneck was clear: developers. As Product Owner, I saw the math: if every client needed custom dev work, we couldn't scale beyond 100-200 restaurants. Our growth target was 7,000+. The solution wasn't hiring more developers—it was empowering clients to customize without developers. Enter: CMS Kiosk.

Why a Standard CMS Wasn't Enough

We evaluated Contentful, Strapi, Sanity—all excellent for blogs and marketing sites. None built for interactive kiosk flows. Here's what we needed that standard CMS platforms couldn't provide:

• Drag-and-drop flow builder: Clients needed to design order flows (Welcome → Menu → Cart → Payment → Confirmation) visually, not in JSON or code. Standard CMS = content management. We needed flow management.
• Conditional logic for non-developers: "If cart > €20, show dessert upsell." "If location = Paris, hide alcohol." Clients needed simple if/then rules without writing JavaScript. Standard CMS had no concept of conditional UI.
• Built-in A/B testing: Clients wanted to test 2 menu layouts, measure which converted better, and automatically switch to the winner. Standard CMS = static content. We needed dynamic experimentation.
• Real-time preview: Change a button color, see it update instantly on a simulated kiosk screen. Standard CMS had "preview" but not device simulation.

The strategic decision: build a custom CMS tailored for kiosks. I pitched this to leadership, aligned R&D director on the vision, and we committed 6 months to building CMS Kiosk as a platform, not a feature.

CMS Kiosk: Architecture Overview

As Product Owner, I defined the vision and coordinated R&D to build it. Here's the high-level architecture:

• Admin Panel (React): Web dashboard where clients log in, configure kiosks, preview changes. Think Shopify admin but for kiosks.
• Flow Builder: Visual editor where clients drag nodes (Welcome, Menu, Cart, Payment) and connect them. R&D built this using react-flow library, coordinated by me to ensure it was simple enough for non-tech users.
• Component Library: Pre-built UI components (buttons, cards, product grids, carousels) that clients mix and match. I worked with UI/UX to design these for maximum flexibility with minimum complexity.
• API Layer: CMS config (JSON schema) gets pushed to kiosks via API. R&D built caching, rollback, and version control so clients could revert if they broke something.
• Preview Mode: Real-time simulation of kiosk screen with client changes applied instantly. This was critical—clients needed confidence before publishing changes to production.

Client Success Stories

CMS Kiosk transformed from vision to reality through real client use cases:

• Burger King - Custom loyalty integration: They wanted to show loyalty points at checkout and offer point-based discounts. Used CMS Kiosk to add a "Loyalty" node between Cart and Payment. Time-to-market: 2 days (vs. 3 weeks if we'd built it custom).
• Quick - Seasonal menu automation: Summer menu vs. winter menu, automated switchover based on calendar dates. CMS Kiosk let them schedule changes weeks in advance. No dev work, no deployment risk.
• Independent chain - Regional menus: 20 locations, each with slightly different menus (local suppliers, regional preferences). CMS Kiosk let them manage all 20 configs from one dashboard, copy/paste between locations, rollout changes selectively.

Result: Average time-to-market for customization dropped from 2-3 weeks to 2 days. Client satisfaction skyrocketed because they controlled their own destiny.

Conclusion: CMS as Competitive Moat

CMS Kiosk wasn't just a feature—it was our competitive moat. Competitors sold kiosks; we sold a platform. Clients who invested time learning CMS Kiosk became sticky—switching to a competitor meant losing all their custom configs, flows, and integrations.

As Product Owner, the lesson: platform thinking beats product thinking. Products scale linearly (more clients = more dev work). Platforms scale exponentially (more clients = more self-service usage). We went from 200 restaurants to 7,000+ without scaling the dev team proportionally. That's platform economics.

Future vision: marketplace of CMS templates. Let clients share their best kiosk configs, create a community-driven template library, and accelerate adoption further. That's the next chapter.