Kukd.com — Mobile Ordering

Project snapshot

• Product: Cross-platform restaurant discovery, food ordering, delivery, and table-booking app
• Role: Lead mobile engineer on a small team
• Engagement: Multi-year Kukd.com client work through Cartes Ltd.
• Delivery: Roughly ten months from June 2021 to April 2022; shipped as v2.2.0
• Contribution: 882 of 1,724 repository commits, the largest individual share

Outcome and scope

I led mobile development for the Expo and React Native application while working with a small engineering team. The mobile app connected to the same ordering platform that powered the Kukd.com website and restaurant-branded white-label sites. My work focused on mobile architecture, typed API integration, basket and session state, payments, real-time order tracking, and release quality.

Customers could discover nearby restaurants, browse and customise menu items, order delivery, book tables, pay through Checkout.com or PayPal, and follow an order from confirmation through preparation and delivery. The product used one Expo and React Native codebase for iOS and Android while integrating with the existing web platform and its business models.

Scroll for more →

System architecture

Text description

The Expo React Native app calls dedicated mobile REST routes for users, restaurants, menus, baskets, and payments. Those routes connect to the broader Node.js consumer API and shared basket and order data. The Kukd.com web platform and hostname-driven white-label restaurant sites use the same business platform through their own routes. Checkout.com and PayPal provide payments. Restaurant kitchen devices process orders and publish updates through Socket.io while connected; the mobile app falls back to polling. Alfonso led the mobile application and contributed to ordering and payment work across the wider platform; the system was built by a team.

The mobile application used typed TypeScript payloads against dedicated routes/rn/* REST endpoints for users, restaurants, menus, baskets, and payments. The smaller mobile payloads remained compatible with the broader Node.js and Express consumer API rather than duplicating its business models.

Kukd.com web ordering and hostname-driven white-label restaurant sites were other surfaces on the same platform. I contributed to their ordering and checkout work, but the wider ecosystem was team-built.

What I owned

• Mobile technical leadership and the largest individual share of repository commits
• Typed mobile API integration across accounts, restaurants, menus, baskets, and payments
• React Query basket state plus Context and useReducer session and location state
• Checkout.com and PayPal flows in the mobile experience
• Socket.io order tracking with polling fallback
• Lint, typechecking, formatting, tests, and release hardening

The commit history makes the boundary inspectable: I contributed 882 of 1,724 commits, the largest individual share; another primary engineer contributed 508, with additional contributors working on features, payments, and release hardening.

Key decisions and trade-offs

• Use Expo for both mobile platforms: Expo reduced native build and module overhead for a cross-platform product with a fixed delivery window. The trade-off was working within the native capabilities and release workflow available to the Expo application.
• Keep mobile routes explicit: Dedicated routes/rn/* endpoints kept payloads focused for mobile while retaining compatible business models with the web platform. The trade-off was maintaining a separate route boundary alongside consumer web endpoints.
• Separate server and client state: React Query handled basket and cart server state, caching, refetching, and synchronization. Context plus useReducer kept session and location transitions explicit without adding another state-management dependency.
• Design status delivery for uneven restaurant connectivity: Socket.io made connected restaurant updates immediate; interval polling preserved order visibility when a kitchen device was not connected.

Technical deep dive

Text description

The customer confirms a basket and fulfillment method in the React Native app. The app submits checkout to the mobile API, which initializes Checkout.com or PayPal. After authorization, the platform creates the order and sends it to the restaurant's kitchen device. While connected, the kitchen device publishes preparation changes through Socket.io. If it is not connected, the app polls the order-status endpoint. The customer sees confirmation, preparation, and delivery progress.

The checkout flow kept mobile responsibilities distinct. The app assembled typed basket and fulfillment data, the dedicated mobile API routed payment initialization to Checkout.com or PayPal, and the team-owned order platform created the authorized order. The restaurant’s kitchen device then drove operational status changes.

For a connected device, Socket.io pushed those changes to the customer. If the device was disconnected, the app polled the order-status endpoint, trading immediacy for a dependable fallback.

Scroll for more →

Production evidence

• Shipped scope: The iOS and Android application shipped as v2.2.0 after roughly ten months of development, from June 2021 to April 2022.
• Measured contribution: Alfonso contributed 882 of 1,724 commits, the largest individual share; another primary engineer contributed 508.
• Automated quality gates: A Husky pre-push hook enforced type-aware ESLint with --max-warnings=0, TypeScript typechecking, Prettier formatting, and Jest tests for form validation, utilities, and shared UI components.
• Operational fallback: Live order updates used Socket.io while a restaurant’s kitchen device was connected, with interval polling of the same order-status endpoint as the fallback.
• Dedicated integration surface: The Node.js and Express backend exposed separate routes/rn/* routers for users, restaurants, menus, baskets, and payments.

See the Kukd.com website for web ordering and payment details, and the white-label restaurant sites for the hostname-driven multi-tenant implementation. If your React Native app needs the same kind of quality-gate and upgrade work, see the React Native audit.