Case study · Restaurant · Food Ordering

Vilka-Lozhka — restaurant-chain ordering app for iOS and Android

Published Aug 18, 2023 · Updated Aug 18, 2023 · By YuSMP Group Engineering

How we rebuilt the mobile apps for a fast-casual restaurant chain from the ground up — native iOS and Android clients on a clean Laravel backend, a combo catalog, a real-time cart, a stable card-acquiring path with recurring payments, a loyalty balance, and pickup-time scheduling — shipped to the App Store and Google Play and engineered to serve audiences across the United States and the European Union under GDPR and CCPA expectations.

IndustryRestaurant · QSR · Food Ordering

Project year2023

EngagementFixed price + support

Vilka-Lozhka restaurant app — menu catalog with set-lunch combos, delivery address, and pickup-time scheduling on iOS

The brief — a restaurant ordering app that actually takes payment

The Vilka-Lozhka product team came to YuSMP Group with a pair of mobile apps that had stopped doing the one thing a food-ordering app has to do reliably: take money. The legacy code had accreted critical bugs, and the payment integration — leaning on broken Apple Pay and Google Pay wiring — failed often enough that customers abandoned orders at checkout. The chain needed a full redesign and a functional rebuild, not a patch: eliminate the inherited defects, replace the payment path with a stable card-acquiring flow that supports both one-time and recurring charges, and refresh the interface so the apps could pass App Store and Google Play review and look current next to delivery-first competitors. The build had to serve buyers in the United States and the European Union from a single codebase, with the privacy posture and disclosures that audiences across the US and EU now expect from any app that holds a card token and a loyalty identity. We treated it as a greenfield rewrite of the order and payment domain — a clean Laravel and React backend, native Swift on iOS and Kotlin on Android — while carrying the menu catalog and loyalty data forward intact.

Project highlights

Native iOS & Android rebuild Laravel + React backend Combo catalog with set lunches Real-time shopping cart math Card acquiring + recurring payments Loyalty balance & redemption Pickup-time scheduling App Store + Google Play live · US & EU

By the numbers

A snapshot of what the Vilka-Lozhka rebuild delivered across iOS, Android, and a clean ordering backend in its first production cycle.

2native platforms — iOS in Swift and Android in Kotlin, separate clients on one Laravel backend

2payment modes — one-time card charges and tokenized recurring payments through one acquiring provider

0card numbers stored in our systems — acquiring returns an opaque token, never the PAN

~40 mintypical order-to-pickup window surfaced in-app so customers schedule a realistic pickup time

2app stores live — Apple App Store and Google Play across US and EU storefronts

10–16 wktypical delivery window for a comparable restaurant-ordering MVP on both stores

Vilka-Lozhka onboarding — farm-fresh breakfasts, lunches, and dinners ready in 40 minutes, with pickup-first messaging

Why a native rebuild over a patch or a white-label ordering SDK

The decision that dominated this project was build-versus-patch. The legacy apps had two failure classes that are uniquely dangerous to patch incrementally: broken payment wiring and unreliable cart arithmetic. Both sit on the money path, where a careless fix double-charges a customer or drops an order, so chasing regressions through accreted code is slower and riskier than a disciplined rewrite of the order and payment domain. We also evaluated white-label restaurant-ordering SDKs and eliminated them: their checkout flows could not host the chain's existing loyalty rules, their acquiring options did not include the recurring-payment path the business needed, and their bundles inflated the IPA and APK past the thresholds the App Store enforces for cellular installs.

Going native on a clean mobile app development stack — Swift on iOS, Kotlin on Android, a Laravel and React backend — let us carry the menu catalog and loyalty data forward while rewriting everything that touches payment, cart state, and order status. The comparison below is the rationale we walked the client through before committing to the rebuild.

Native rebuild vs patching legacy vs white-label ordering SDK — at a glance
Dimension	Native rebuild (Vilka-Lozhka)	Patch legacy code	White-label SDK
Payment path stability	Rewritten on one acquiring provider with idempotency	Inherited broken Apple/Google Pay wiring	Vendor-fixed; recurring often unavailable
Recurring payments	Tokenized, supported from day one	Not present; hard to retrofit safely	Depends on vendor; rarely flexible
Loyalty rules	Custom ledger, chain's own rules preserved	Fragile counters prone to corruption	Vendor's loyalty model, not the chain's
App bundle size	Lean native binaries per platform	Carries dead code and old deps	SDK bloat past cellular-install limits
Store approval risk	Clean privacy disclosures, fresh UI	Legacy rejections likely to persist	Shared SDK rejections affect all clients
Catalog & data migration	Menu + loyalty carried forward intact	Stuck in old schema	Re-model into vendor schema
Long-term ownership	Client owns full source and roadmap	Owns brittle code, debt compounds	Locked to vendor pricing and roadmap

Platform references: Apple StoreKit and in-app payment documentation, Google Play Billing reference, PCI Security Standards Council.

Vilka-Lozhka phone-based registration — single-field number entry with numeric keypad and user-agreement consent on iOS

iOS build — Swift, phone-based onboarding, and the combo catalog

The iOS client is built in Swift, and the first thing we collapsed was the sign-up flow. The legacy apps asked for too much before a customer could see a price; the rebuilt flow opens on a single phone-number field with a numeric keypad and an inline user-agreement consent, so a first-time buyer is one SMS code away from browsing. From there the catalog leads with the chain's set-lunch combos — the highest-margin, fastest-moving items — followed by salads, fish dishes, soups, and sides, each with a thumbnail, price, and a stepper that writes straight into the cart without a full-screen modal in between.

The catalog is data-driven from the Laravel backend, so the operations team re-prices items, swaps the day's set lunch, and toggles availability per location without an app release. Pickup-first messaging is baked into the home screen — a delivery address and a "specify pickup time" control sit above the catalog, and the onboarding sets the expectation that a farm-fresh order is ready in roughly 40 minutes. The same engineering team carries iOS and Android in lockstep as part of our iOS and Android engineering practice, so the catalog model, cart math, and loyalty rules behave identically on both platforms.

Vilka-Lozhka basket — grouped line items with per-item containers, real-time total, and a checkout call to action on Android

Android build — Kotlin, the real-time cart, and pickup scheduling

The Android client is written in Kotlin and shares the cart and order model with iOS through the Laravel backend. The basket is where a food app earns trust: line items are grouped, each carries its own container charge where the menu requires it, and the running total recalculates instantly as steppers change — no spinner, no round-trip per tap, because the pricing rules are mirrored client-side and reconciled against the server only at checkout. That mirrored-then-reconciled pattern is what eliminated the cart-math bugs that plagued the legacy build, where the displayed total and the charged total could drift apart.

Checkout folds three decisions into one screen: the pickup location, an optional order comment, and a pickup time the customer can shift, with the app surfacing the realistic "ready in about 40 minutes" estimate rather than promising an impossible slot. The loyalty toggle lives here too — a customer can apply bonuses for a discount of up to 30% of the order total, and the discount is computed server-side so the figure the customer sees is the figure the kitchen and finance team see. Building the cart and checkout on a clean foundation is the kind of custom software development that pays for itself the first week a chain stops losing orders at the payment step.

Vilka-Lozhka payment confirmation — order successfully paid screen with operator-callback messaging and PCI-DSS-aligned token handling

Payment architecture, tokenized acquiring, and data hardening

The payment rebuild was the heart of the engagement. We replaced the broken wallet wiring with a direct card-acquiring integration that the backend drives, supporting both a one-time charge and a tokenized recurring path so a returning customer reorders without re-entering card details. The application never stores a card number — the acquiring provider returns an opaque token that maps to the customer record, and every charge runs against that token under PCI-DSS-aligned handling. Settlement webhooks confirm the money landed before the order is released to the kitchen, idempotency keys make retries safe so a flaky network never produces a double charge, and refunds reconcile against the same token so the operator dashboard never disagrees with reality. The "your order has been successfully paid" confirmation is only shown after the webhook clears, not optimistically.

On the data side, the rebuild was structured for audiences across the US and EU from the start. Personal data is minimized to the phone number and order history a pickup order actually needs; the loyalty balance is an append-only ledger rather than a mutable field; and consent is captured explicitly at registration. The posture aligns with GDPR obligations for users in the European Union and CCPA / CPRA obligations for users in California and the broader United States.

Compliance posture: GDPR-aligned · ISO 27001 ready · SOC 2 Type II in progress · HIPAA-capable · CCPA-acknowledged.

Delivery methodology

A five-phase rebuild that took Vilka-Lozhka from a broken legacy app to a stable, store-approved release across iOS, Android, and a clean ordering backend.

Phase 1

Discovery & defect audit

Catalogued the legacy critical bugs, mapped the broken payment path, scoped the catalog and loyalty data to carry forward, and set the GDPR + CCPA posture for US and EU audiences.

Phase 2

Backend & payment design

Clean Laravel + React backend, catalog and loyalty ledger schema, acquiring integration design with one-time and tokenized recurring charges and idempotent settlement webhooks.

Phase 3

Native platform builds

Swift iOS client and Kotlin Android client sharing one order model: phone onboarding, combo catalog, real-time cart, pickup scheduling, and the loyalty redemption toggle.

Phase 4

Payment hardening & QA

End-to-end payment QA — double-charge prevention, refund reconciliation, cart-math parity between client and server, and PCI-DSS-aligned token handling under load.

Phase 5

Store launch & support

App Store and Google Play submission with refreshed UI and privacy disclosures across US and EU storefronts, followed by an operator-feedback and stabilization window.

Loyalty, the operator back office, and the entitlement bridge

The loyalty program was the subsystem we were most careful with, because a restaurant chain lives or dies on whether the number a customer sees at checkout matches what the kitchen and finance team see in the back office. We built the balance as an append-only ledger rather than a mutable counter: points accrue only on settled orders, redemptions are capped per order as a business rule — a discount of up to 30% of the order total — and every accrual or burn is a ledger entry the operator dashboard reads from directly. That design makes disputes auditable and lets the chain run promotions without corrupting historical balances, because a promotion is just a new accrual rule layered on top of the same immutable history. The operator back office reads the same single source of truth the app does, so a manager reconciling the till never has to guess which system is authoritative. The whole subsystem was built for extensibility: adding a multi-location loyalty tier, a referral bonus, or a corporate-account program is a configuration change against the ledger and entitlement service rather than a client release, which keeps the chain off the App Store and Google Play review treadmill for routine marketing changes.

Launching across the United States and the European Union

The Vilka-Lozhka apps were built to ship on Apple App Store and Google Play with storefronts active across the United States and the European Union from a single codebase. The same build serves buyers in California, New York, Texas, Florida, and Washington in the US, and in the Netherlands, Germany, France, Ireland, and Sweden in the EU, without a separate app per region. Consent flows are region-aware at the client layer: users in the EU and EEA receive a GDPR-style granular consent screen with separate toggles for any optional product analytics, while users in California receive a CCPA-style "Do Not Sell or Share My Personal Information" disclosure in the same flow. Data-handling practices are aligned with GDPR for European users and with the US state-privacy patchwork — CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas), and Oregon CPA. Because the app minimizes personal data to a phone number and order history, regional compliance reduces to honest disclosure rather than per-jurisdiction data segregation.

Payment and acquiring were the area we hardened most for a cross-market rollout: the tokenized acquiring layer abstracts the provider behind a single interface, so swapping or adding a regional acquirer for the US or EU is a backend configuration change rather than a client rebuild. Both the App Store age rating and the Google Play content rating were calibrated for a food-ordering feature set with payments, citing GDPR obligations and California CCPA obligations directly in the in-app privacy policy. The engineering team behind the build sits across CET and runs a CET workday with East-Coast US overlap (9 AM–1 PM ET) for stand-ups, store-review choreography, and incident response — the timezone that lets a US product team and an EU engineering team share four hours of live overlap every day.

Tech stack and roadmap

Swift SwiftUI Kotlin Jetpack Compose PHP Laravel React REST API PostgreSQL Redis Card acquiring Recurring payments Apple StoreKit Google Play Billing Docker Nginx Prometheus Grafana

The active custom software development roadmap for Vilka-Lozhka includes a delivery mode alongside the current pickup flow with courier dispatch, a multi-location loyalty tier with corporate accounts, push-driven re-order prompts tied to the loyalty ledger, and a web ordering surface that shares the same Laravel backend. Infrastructure plans include adding a second regional acquirer behind the existing tokenized payment interface for US and EU coverage, and richer operator analytics built into the cloud & DevOps roadmap so the chain can see basket size, redemption rate, and pickup-time accuracy per location in near real time.

Build a restaurant ordering app like this — talk to us

If you are planning a restaurant or QSR ordering app, replacing a broken payment integration, or rebuilding a legacy food app that has stopped converting at checkout for audiences in the US and EU, we have shipped this stack end-to-end and can compress the build timeline meaningfully. The full case is documented at yusmpgroup.com/cases/vilka-losja (iOS and Android), and the engineering team behind it sits inside YuSMP Group. We work fixed-price for well-scoped MVPs and on dedicated development teams for ongoing delivery, with a CET workday and a guaranteed East-Coast US overlap (9 AM–1 PM ET) window for stand-ups, demos, and incident response.

Book a discovery call See mobile development services

Frequently asked questions

How much does it cost to build a restaurant food-ordering app like this?

A focused restaurant-chain ordering MVP covering native iOS and Android clients, a combo catalog, a real-time cart, one acquiring provider, and pickup scheduling typically costs $90k–$200k. Adding a loyalty program, recurring billing, multi-location support, kitchen and operator integrations, and analytics brings a full-featured product to $220k–$450k. The dominant cost drivers are the payment and acquiring integration, the loyalty and entitlement logic, and keeping two native clients in lockstep across iOS and Android.

Why rebuild a legacy restaurant app instead of patching it?

Legacy food-ordering apps usually fail on the payment path and the cart math first, and those are the hardest places to patch safely because each fix risks double-charging or losing an order. When the acquiring integration is broken and the codebase has accreted critical bugs, a disciplined rebuild on a clean Laravel backend with native Swift and Kotlin clients is faster to a stable, store-approved release than chasing regressions through old code. We carried the catalog and loyalty data forward while rewriting the order and payment flow from first principles.

How do you integrate recurring card payments into a food-ordering app?

Card acquiring for a food app needs both one-time charges and a tokenized recurring path so returning customers can reorder without re-entering card details. The app never stores the full card number — the acquiring provider returns an opaque token that maps to the customer record, and the backend charges against that token under PCI-DSS-aligned handling. Webhooks confirm settlement before the order is released to the kitchen, idempotency keys prevent double charges on retries, and refunds are reconciled against the same token so the operator dashboard stays consistent.

What does a loyalty program need on the backend of a restaurant app?

A loyalty program needs a single source of truth for balance that both the app and the operator back office read from, so the number a customer sees at checkout always matches what the kitchen and finance team see. Points accrue on settled orders only, redemptions are capped per order as a business rule (here, a discount of up to 30% of the order total), and every accrual or burn is an append-only ledger entry rather than a mutable counter. That ledger makes disputes auditable and lets the chain run promotions without corrupting historical balances.

How long does it take to ship a restaurant ordering app on iOS and Android?

A focused MVP with native iOS and Android clients, a combo catalog, a real-time cart, one acquiring provider, and pickup scheduling typically takes 10–16 weeks. Adding a loyalty program, recurring billing, multi-location support, and operator integrations adds 6–10 weeks. The store-approval pass — privacy disclosures, payment-policy review, and the App Store and Google Play submission choreography — is frequently underestimated and should be budgeted at 3–5 weeks of dedicated work.

Related cases

More mobile & commerce platform builds

Food · Delivery

Share this case

LinkedIn X

Plan a similar build

Book a discovery call

← Previous case Lucky Shrimp Next case → Delivery