Food Delivery Platform for Underserved Cities by Adnan AslamFood Delivery Platform for Underserved Cities by Adnan Aslam

Food Delivery Platform for Underserved Cities

Adnan Aslam

Completed work

Android Developer

iOS Developer

Expo

React Native

Supabase

E-Commerce

FUDGO — Building a Food Delivery Platform for Underserved Pakistani Cities

FUDGO is a food delivery platform created for communities outside Pakistan's largest, best-served metropolitan markets.

The product connects customers with local restaurants through a mobile-first ordering experience, supported by a web application and a realtime backend. Customers can discover restaurants and food categories, view menu items, build their cart, place orders, and manage their activity through one accessible mobile experience.

I worked across the product architecture and implementation, including the React Native application, Next.js web application, authentication, database-backed workflows, realtime synchronization, and server-side Supabase Edge Functions.

FUDGO is publicly available on Google Play and has surpassed 10K downloads. Its store listing describes the product as a food delivery application for underserved areas and small cities of Pakistan.

FUDGO is publicly available on Google Play and has surpassed 10K downloads.

FUDGO is publicly available on Google Play and has surpassed 10K downloads.

The challenge

Most food delivery products are designed around dense urban markets with large restaurant networks, mature logistics, standardized addressing, and customers already familiar with app-based ordering.

FUDGO was designed for a different environment.

The platform needed to support smaller cities and underserved communities where:

Local restaurants may have limited digital infrastructure

Menu information can change frequently

Users require a straightforward ordering flow

Operational teams need immediate visibility into changing order states

Mobile connectivity and device performance cannot be taken for granted

The system must remain manageable without enterprise-scale operational resources

The challenge was therefore larger than creating an attractive restaurant-listing application.

The product needed a connected technical foundation capable of supporting customers, restaurants, operational users, menu data, carts, orders, authentication, and realtime state changes across mobile and web experiences.

What I built

Customer mobile application

I built the customer-facing experience with React Native.

The application provides a structured ordering journey:

Restaurant and food discovery

Category browsing

Menu and item details

Cart management

Order placement

Order-related activity

Customer account and profile access

The interface was designed around a familiar mobile-commerce pattern so users could understand the application without extensive onboarding.

The goal was not to introduce unusual interactions. It was to make local food ordering feel direct, predictable, and accessible.

Mobile-first restaurant and food discovery designed for fast browsing across local menus and categories.

Mobile-first restaurant and food discovery designed for fast browsing across local menus and categories.

Restaurant and menu discovery

Customers can explore available food options through restaurant listings, categories, featured items, and individual product pages.

Menu data needed to support more than a static name and price. The platform had to represent:

Restaurant ownership

Cart and ordering workflow

The cart connects customer selections to the underlying restaurant and menu records.

The workflow needed to preserve:

Selected products

Product quantities

Prices

Restaurant associations

Customer ownership

Order totals

The transition from cart state to order state

I kept the ordering logic structured so that the mobile application did not become the sole authority for important transactional behavior.

Business-sensitive operations could instead be handled through the backend and server-side functions.

Cart workflow maintaining product quantities, restaurant associations, pricing, and order preparation in one clear mobile flow.

Cart workflow maintaining product quantities, restaurant associations, pricing, and order preparation in one clear mobile flow.

Supporting web application

I built a Next.js web application to support the wider platform outside the customer mobile experience.

This provided a web-based foundation for the operational and administrative parts of the product, while sharing the same backend data model as the mobile application.

Using separate mobile and web interfaces allowed each surface to be designed around its actual user:

Mobile for customer discovery and ordering

Web for data-heavy operational workflows

Supabase as the shared source of truth

This avoided duplicating backend logic across disconnected systems.

Realtime platform behavior

Food delivery is a state-driven workflow.

An order can move through multiple stages, and those changes may need to appear across different user interfaces without requiring constant manual refreshes.

I used Supabase Realtime as part of the architecture so relevant state changes could be synchronized across the platform. The broader FUDGO implementation combines Supabase Realtime with authentication, database services, and Edge Functions.

This architecture was suitable for workflows where the customer-facing application and operational web application needed to remain aligned around current backend data.

Authentication and controlled access

Supabase Auth provides the identity layer for the platform.

Authentication was integrated into the product architecture rather than added as an isolated login screen. User identity is relevant to:

Customer profiles

Cart ownership

Order ownership

Role-specific application behavior

Protected data access

Server-side operations

The important architecture decision was to avoid trusting user-supplied identifiers for ownership-sensitive actions.

Authenticated identity and backend validation provide a more reliable foundation for controlling which records a user can access or modify.

Server-side workflows with Edge Functions

Some actions should not be performed entirely inside a mobile application.

I used Supabase Edge Functions for server-side workflows that required controlled execution, privileged backend access, or integration logic that should not be exposed to the client.

This helped separate:

User-interface state

Database persistence

Privileged business operations

External integrations

Backend validation

The result was a cleaner boundary between what the customer application displays and what the backend authoritatively processes.

My process

1. Start with the complete product journey

I mapped the customer journey before treating individual screens as separate features:

Discover → Browse menu → Select items → Manage cart → Place order → Follow activity

This established the core entities and relationships needed by the platform.

It also prevented an early mistake common in marketplace products: building polished screens before defining how the underlying customer, restaurant, menu, cart, and order states connect.

2. Design the shared data model

The mobile application and web application needed to operate against the same platform state.

I structured the backend around core product domains such as:

Users

Customer profiles

Restaurants

Menu categories

Products

Carts

Cart items

Orders

Order items

Status changes

The objective was to make each record's ownership and relationships explicit.

This made the system easier to reason about and reduced the risk of contradictory data appearing across mobile and web surfaces.

3. Separate client and server responsibilities

I avoided placing all business behavior inside React Native components.

The mobile client handles user interaction and presentation, while the backend remains responsible for persistent data and protected operations.

The architecture distinguishes between:

Local interface state

Authenticated user state

Persistent platform records

Realtime subscriptions

Server-side functions

This separation made the application more secure and easier to evolve.

4. Build mobile and backend workflows together

I did not build the mobile application against static mock data and postpone backend integration until the end.

Each major customer flow was connected incrementally:

Define the data needed by the screen.

Connect it to authenticated backend records.

Implement loading, empty, and failure states.

Validate navigation between related steps.

Confirm that mutations persisted correctly.

Verify that realtime changes did not create conflicting local state.

This exposed product and data-model problems earlier than a frontend-first process would have.

5. Optimize for real mobile conditions

FUDGO was created for markets where users may not always have flagship phones or ideal connectivity.

That influenced practical decisions around:

Avoiding unnecessary screen complexity

Keeping navigation familiar

Reducing excessive client-side processing

Making loading and empty states understandable

Avoiding unnecessary network requests

Keeping important actions clear

Using backend-driven state instead of fragile local assumptions

The application needed to feel dependable before it needed to feel technically impressive.

6. Launch, observe, and improve

Publishing the application was not treated as the final engineering milestone.

A live consumer product introduces issues that development environments cannot fully reproduce:

Different Android devices

Variable connection quality

Unexpected user navigation

Incomplete customer information

Rapid menu and availability changes

Production authentication states

Store-release and deployment constraints

I continued improving the platform based on how the system behaved as a live product rather than assuming the initial implementation would remain sufficient.

Architecture decisions

React Native for the customer application

React Native provided a practical balance between native mobile delivery and maintainable product development.

It allowed the customer experience to be built around mobile interaction patterns while retaining a shared JavaScript and React development model.

This was valuable for:

Faster iteration

Android delivery

Reusable application patterns

Consistent state handling

Easier coordination with the React/Next.js web stack

Next.js for the web platform

Next.js was used for the supporting web application.

This provided a structured foundation for interfaces that benefit from:

Larger-screen layouts

Operational data presentation

Server-aware application behavior

Protected routes

Backend integration

Maintainable React components

The mobile and web applications serve different usage contexts, but both connect to the same backend platform.

Supabase as the shared backend

Supabase provided the backend foundation through:

Authentication

Database

Realtime synchronization

Edge Functions

Shared access from mobile and web clients

This kept the early platform operationally lean while still supporting a production application with multiple interfaces. The confirmed FUDGO stack includes React Native, Next.js, Supabase Realtime, Auth, database services, and Edge Functions.

The decision reduced the need to maintain separate infrastructure for authentication, realtime transport, backend functions, and relational data during the initial product lifecycle.

Shared backend architecture connecting the React Native customer application, Next.js web platform, authentication, realtime updates, database records, and server-side functions.

Shared backend architecture connecting the React Native customer application, Next.js web platform, authentication, realtime updates, database records, and server-side functions.

Relational modelling for marketplace data

Food delivery is fundamentally relational.

A customer selects products that belong to menus, menus belong to restaurants, carts contain selected items, and orders preserve transactional versions of those selections.

A relational backend was therefore more appropriate than storing the platform as loosely connected documents.

It provided clearer ownership, filtering, consistency, and reporting behavior.

Realtime only where it created product value

Realtime technology was not used simply because it was available.

It was applied where changing backend state could materially affect the user or operational experience.

This avoids a common architecture problem: subscribing every screen to everything, creating unnecessary network activity and difficult-to-debug state behavior.

Edge Functions for privileged operations

Sensitive operations and integration logic were kept outside the distributed mobile client.

This improves:

Secret management

Input validation

Authorization

Consistency

Maintainability

The ability to change backend behavior without forcing every rule into the mobile application

One backend across multiple product surfaces

The mobile and web applications were not implemented as independent products with duplicated data.

They share the same backend foundation.

This was an important scaling decision because restaurant, product, customer, and order information should remain consistent regardless of which interface creates or reads it.

Results

The clearest externally verifiable product result is that FUDGO reached 10K+ Google Play downloads.

The platform was successfully delivered as a working product comprising:

A published React Native mobile application

A supporting Next.js web application

Authentication

A persistent relational backend

Realtime platform behavior

Server-side Edge Functions

A complete customer ordering journey

FUDGO demonstrates my ability to move beyond an isolated feature or prototype and build a connected consumer platform across mobile, web, backend, and production release.

Results summary

My role

I led the full-stack product engineering across the React Native customer application, Next.js web application, Supabase backend, authentication, realtime data flows, database architecture, and Edge Functions. My work covered the complete path from product workflows and interface implementation to backend integration, production deployment, and continued improvement of the live application.