Softavera Kiosk: Leading International Self-Service Restaurant System Transformation

Executive Summary

Between January 2020 and June 2021, I served as Product Owner and UI/UX Supervisor for Softavera Groupe's most ambitious project: a complete transformation of their restaurant self-service kiosk system. This wasn't an incremental improvement—it was a ground-up rebuild necessitated by the fundamental limitations of our legacy WinDev platform.

Leading a 17-person team (2 Project Managers, 10 Developers, and 5 QA Engineers), I coordinated an 18-month international deployment across four countries: France, USA, UK, Germany, and Australia. The project delivered a modern React-based platform with a proprietary CMS Kiosk that empowered clients to customize their ordering flows without developer intervention—a game-changing capability that accelerated time-to-market from weeks to days.

The results exceeded expectations: 7,000+ restaurants now operate on our platform with 95% end-user adoption, achieving 30% reduction in order time and +15% average cart value increase. This case study details the product management strategy, technical decisions, and lessons learned from transforming a Windows-only legacy system into a modern, internationally-compliant platform.

The Challenge: Breaking WinDev's Limitations

When I joined Softavera in late 2019, the company faced a strategic impasse. Our existing kiosk system, built entirely in WinDev, was technically functional but fundamentally incompatible with international expansion. WinDev's Windows-only deployment model meant we couldn't support the Android tablets, web browsers, or hybrid devices that international clients demanded.

The technical limitations were only part of the problem. The closed WinDev ecosystem made recruiting difficult—finding developers with WinDev expertise was a constant challenge. Integration with modern payment gateways required custom workarounds. And most critically, each client customization required engineering time we didn't have, creating a bottleneck that prevented scale.

But the real catalyst was regulatory compliance. As we pursued opportunities in France, USA, UK, Germany, and Australia, we discovered that each country's fiscal and accessibility requirements demanded architectural changes that WinDev simply couldn't accommodate. France's NF525 certification for fiscal data integrity, PMR accessibility standards for reduced mobility users, and varying international data privacy laws all pointed to the same conclusion: we needed a modern, web-native platform built on international standards.

The decision was clear: migrate to a modern web stack. The execution, however, would be anything but simple.

Product Vision & Strategy

Our product vision went beyond simply rebuilding existing functionality. We aimed to create a platform that empowered our clients to customize their ordering experiences without engineering support. This meant designing a CMS-first architecture where menu configurations, ordering flows, UI themes, and promotional content could all be modified through intuitive visual interfaces.

The CMS Kiosk Strategy

The centerpiece of our strategy was developing a proprietary CMS Kiosk system. Unlike traditional CMS platforms designed for websites, ours needed to handle the unique requirements of ordering flows: conditional logic (if cart value exceeds €20, suggest desserts), multi-step processes (welcome → browse → cart → payment → confirmation), and real-time menu updates synchronized with inventory systems.

Phased Roadmap: Discovery, Build, Scale

We structured the 18-month timeline into three phases:

• Phase 1 - Discovery (3 months): Stakeholder interviews, requirements gathering, technical architecture design, and pilot client selection
• Phase 2 - Build (9 months): Core platform development, CMS Kiosk creation, payment gateway integrations, and pilot deployments with Burger King La Réunion and Quick
• Phase 3 - Scale (6 months): International deployment, compliance certifications (NF525, PMR), performance optimization, and rollout to 7,000+ locations

Success Metrics That Mattered

From day one, we defined clear success metrics: 95% end-user adoption (staff willingness to use the system), sub-30-second ordering time, +10% cart value uplift, and 4.5/5 satisfaction scores from both restaurant staff and customers. These weren't aspirational targets—they were contractual commitments to pilot clients that shaped every product decision.

Team Structure & Agile Methodology

As Product Owner, I coordinated a 17-person cross-functional team organized into specialized pods:

• 2 Project Managers: One focused on technical delivery, the other on client relationships and deployment logistics
• 10 Developers: Split into frontend (5), backend (3), and CMS/tooling (2) teams. Each team operated semi-autonomously with clear domain ownership
• 5 QA Engineers: Dedicated to automated testing, manual QA, performance benchmarking, and compliance verification

My role extended beyond traditional Product Owner responsibilities. I also served as UI/UX Supervisor, ensuring design decisions aligned with user research and A/B testing data rather than subjective preferences.

Agile Implementation: Two-Week Sprints

We adopted Agile with two-week sprints, a cadence that proved essential for maintaining team momentum while allowing time for thorough QA. Each sprint followed a consistent rhythm:

• Day 1 (Monday): Sprint planning where I presented refined user stories with acceptance criteria. My responsibility was ensuring developers had sufficient context to estimate accurately without needing constant clarification
• Daily (15 min): Standups focused on blockers and dependencies, not status reports. I actively resolved impediments same-day
• Day 9 (Thursday): Mid-sprint check-in to catch scope issues before week 2
• Day 10 (Friday - Week 2): Sprint review with stakeholders, followed by retrospective where we celebrated wins and addressed process friction

The two-week cadence was critical. It was long enough to complete meaningful features, but short enough to pivot quickly when pilot feedback revealed unexpected pain points. Over 36 sprints, we maintained an 85% on-time delivery rate—a figure I'm proud of given the project's complexity and international coordination challenges.

Technical Architecture: Modern Stack for Global Scale

While my primary role was product management, I worked closely with our technical leads to shape an architecture that balanced immediate needs with future scalability. The transition from WinDev to a modern web stack wasn't just about technology—it was about enabling business capabilities that were previously impossible.

Frontend: React with Multi-Device Responsiveness

We chose React for its component-based architecture, which perfectly aligned with our CMS Kiosk strategy. Each UI element—menu item cards, cart summaries, payment forms—was built as a reusable component with configurable props controlled by the CMS. This meant clients could swap button styles, rearrange layouts, or toggle features without touching code.

The responsive design wasn't an afterthought—it was essential for international deployment. USA clients preferred 27-inch touchscreen monitors, while European chains often used 15-inch tablets. Our design system accommodated both with adaptive layouts that maintained usability across devices.

Backend: Node.js Cloud Infrastructure

Our Node.js backend ran on AWS with PostgreSQL for transactional data and Redis for session caching. The architecture prioritized resilience over peak performance—an ordering system that's fast 99% of the time but crashes during lunch rush is worthless. We implemented extensive fallback mechanisms: if payment processing failed, the system gracefully degraded to cash-only mode while logging the issue for later reconciliation.

CMS Kiosk: The Client Empowerment Engine

The CMS Kiosk was our competitive differentiator. Built as a separate React application, it provided restaurant managers with a drag-and-drop flow builder for designing ordering journeys. Want to add an upsell prompt after adding burgers to the cart? Drag the "upsell" node between "cart" and "payment" steps. Need to A/B test two menu layouts? Create two variants and let the system automatically split traffic and track conversions.

The CMS configuration was stored as JSON schemas that the kiosk runtime interpreted at render time. This architecture meant changes went live instantly without deployments—a game-changer for clients who previously waited weeks for customization requests.

Integration Layer: Payments & POS Systems

Payment integration was among our most complex technical challenges. Each country had preferred providers: Stripe for USA/UK, Adyen for Europe, and various local gateways elsewhere. We built an abstraction layer that normalized payment flows across providers, allowing restaurants to switch providers by changing a configuration flag rather than rewriting code.

POS system integration with Cashpad and Merim required real-time order synchronization. We implemented webhook-based communication with automatic retry logic—if the POS system was temporarily offline, orders queued locally and synchronized when connectivity restored. This "degraded mode" capability was non-negotiable; restaurants can't afford to stop taking orders due to network hiccups.

Key Features & Innovations

The platform delivered several industry-first capabilities that became our primary selling points to international clients:

• CMS Kiosk Self-Service Customization: Restaurant managers could modify ordering flows, menu layouts, promotional banners, and UI themes without developer support. Time-to-market for changes dropped from 2+ weeks to same-day
• Offline Resilience (Degraded Mode): When network connectivity failed, kiosks continued accepting orders with locally cached menus and payment data. Orders synchronized automatically when connectivity restored, preventing revenue loss during outages
• Multi-Language & Multi-Currency: Support for 8+ languages with right-to-left text support for Arabic markets. Currency conversion with real-time exchange rates for international franchise operators
• NF525 Fiscal Compliance (France): Built-in audit trails, immutable transaction logs, and certified hardware integrations to meet France's strict fiscal certification requirements. This compliance became a key differentiator in French markets
• PMR Accessibility: WCAG 2.1 AA compliance with adjustable touch target sizes, high-contrast modes, voice guidance integration, and keyboard navigation. These weren't add-ons—they were core design requirements from day one
• Unified Payment Gateway Abstraction: Support for Stripe, Adyen, and regional providers with automatic failover. If primary gateway failed mid-transaction, the system seamlessly switched to backup provider without customer awareness
• Real-Time Analytics Dashboard: Restaurant managers accessed live metrics on order volumes, average cart values, popular items, and conversion funnels. This data directly informed menu optimization decisions
• Conversion-Optimized UI Patterns: Based on extensive A/B testing with pilot clients, we implemented proven patterns like strategic upsell placement, progress indicators, cart persistence, and one-tap reordering. These UX decisions contributed directly to the +15% cart value increase

International Deployment: Navigating Regulatory Complexity

Deploying across four countries meant compliance became a product management challenge, not just a legal checkbox. Each market had unique requirements that shaped our roadmap:

France (NF525): Required certified fiscal modules, immutable transaction logs, and government-approved hardware. Certification process took 4 months and required extensive documentation. USA: State-specific sales tax requirements meant supporting 50+ tax jurisdictions. UK/EU (GDPR): Data privacy laws required EU-based servers and explicit consent workflows. Australia: Consumer protection standards demanded transparent pricing and easy order cancellation flows.

Key Takeaways: Product Leadership Lessons

After 18 months leading this transformation, several lessons shaped my approach to product management:

• Multi-team coordination is the hardest part: Technical excellence means nothing if teams aren't aligned. My most valuable time wasn't spent writing requirements—it was resolving conflicts, clarifying priorities, and ensuring everyone understood the "why" behind decisions
• Agile works when adapted, not followed religiously: Two-week sprints were perfect for us, but we flexibly adjusted ceremonies as needed. Retrospectives drove real change because we acted on feedback rather than just collecting it
• CMS-first architecture = scalability unlock: Investing 3 months in CMS Kiosk development delayed feature delivery, but unlocked client self-service that would've been impossible otherwise. Strategic technical investments pay exponential dividends
• Quality gates aren't bureaucracy—they're insurance: Zero critical production bugs in the first 6 months didn't happen by accident. Rigorous QA processes felt slow during development but prevented catastrophic failures in production
• Stakeholder alignment > perfect requirements: We pivoted multiple times based on pilot feedback. Having stakeholder buy-in made those pivots smooth rather than contentious. Weekly stakeholder updates weren't optional—they were essential
• Data-driven design beats opinions: A/B testing settled countless debates. When we had data showing which menu layout converted better, subjective design preferences became irrelevant. Every significant UI decision was backed by user testing or analytics

The Softavera Kiosk transformation was the most challenging project of my career. Managing 17 people across technical, QA, and stakeholder domains while delivering international deployment taught me that product management is fundamentally about people, not processes. The technical stack, CMS architecture, and compliance frameworks were all important—but success ultimately came down to clear communication, decisive conflict resolution, and relentless focus on measurable outcomes.