Home Food — Two-Sided Home-Cooked Food Marketplace Platform

Android · Java · WordPress · Custom API · Provider Marketplace · Customer Ordering · Delivery Fulfillment · Payments · Telegram Notifications

A production two-sided marketplace launched around 2018 to connect approved home cooks with local customers seeking fresh, hot, home-prepared meals. The platform combined two Android applications, provider onboarding and availability, customer ordering, delivery fulfillment, multiple payment flows, cook settlement workflows, a WordPress-based administrative back office, and a custom API layer created to overcome limitations in the existing WordPress/Dokan integration.

1. Executive Summary

Home Food was a two-sided digital marketplace for home-cooked meals.

The core idea was simple:

Enable home cooks—especially people cooking from home—to offer meals during the hours they were available, while allowing nearby customers to order fresh, hot, homemade food through a mobile application.

The system was not a single Android application.

It was a multi-part platform consisting of:

a provider / home-cook Android application,
a customer Android application,
a WordPress-based management back office,
an existing marketplace/database layer,
a custom API layer built to expose the required data reliably,
SMS-based authentication,
provider approval workflows,
food availability and schedule management,
customer ordering,
delivery coordination,
payment handling,
provider settlement,
ratings / reviews / ranking,
management messaging,
and an alternative Telegram-based notification integration when Firebase push notifications were not usable in the target environment.

The platform was delivered to the customer, launched, and remained operational for several years.

The business later ceased for non-technical organizational reasons, not because the software concept failed technically.

2. Professional Positioning

This project is best described as:

A production two-sided home-food marketplace connecting approved home cooks with local consumers through Android applications, custom API integration, administrative workflows, payment/settlement logic, and last-mile delivery coordination.

A weak description would be:

“I made a food-ordering Android app.”

That would miss most of the engineering scope.

The real system was closer to:

Home Cooks / Providers
        │
        │ availability, menu, capacity
        ↓
Provider Android App
        │
        ├──────────────┐
        │              │
        ↓              ↓
Custom API        Admin / WordPress
        │              │
        └──────┬───────┘
               │
         Marketplace Data
               │
        ┌──────┴───────┐
        │              │
        ↓              ↓
Customer App      Management
        │
        ↓
Orders / Payments
        │
        ↓
Delivery / Courier
        │
        ↓
Customer Receives
Fresh Home-Cooked Food

3. Period

Approximate development period:

2018

The archived Android project indicates a technology snapshot around the Android SDK 28 generation, which is consistent with this timeframe.

4. Business Problem

The marketplace addressed two complementary needs.

Supply Side

Many skilled home cooks could prepare high-quality food but did not operate formal restaurants.

They needed a way to:

register,
be approved,
declare when they were available to cook,
choose which foods they could prepare,
publish available meals,
receive orders,
build reputation,
and receive settlement.

Demand Side

Customers wanted:

fresh,
hot,
homemade food,
local availability,
a simple ordering workflow,
delivery,
and alternatives to conventional restaurant food.

Home Food connected these two sides.

5. Marketplace Model

At a high level:

              HOME FOOD
                  │
      ┌───────────┴───────────┐
      │                       │
      ↓                       ↓
 Home Cook               Customer
 / Provider               / Buyer
      │                       │
      │ availability          │ demand
      │ menu                  │ browse
      │ capacity              │ order
      └───────────┬───────────┘
                  │
                Order
                  │
                  ↓
               Courier
                  │
                  ↓
              Delivery

This was fundamentally a two-sided marketplace with operational fulfillment.

6. Core Actors

The system involved at least four operational actors:

6.1 Home Cook / Provider

Responsible for:

registration,
identity/profile information,
cooking capabilities,
availability,
food selection,
menu/listing management,
order fulfillment,
reviews,
financial balance,
and communication.

6.2 Customer

Responsible for:

registration/login,
browsing available food,
selecting food,
placing orders,
choosing payment options,
receiving delivery,
and rating/reviewing.

6.3 Delivery / Courier

Responsible for:

Cook Pickup
    ↓
Transport
    ↓
Customer Delivery

Courier support initially leveraged an external food-delivery/logistics relationship inspired by or connected to the existing Snappfood delivery ecosystem.

The exact later courier implementation changed over time and should not be overstated without additional evidence.

6.4 Management / Administrator

Management primarily had a supervisory role through the WordPress-based administrative environment.

Responsibilities included:

provider approval,
marketplace oversight,
user supervision,
operational review,
financial monitoring,
and content / marketplace management.

7. Two Separate Android Applications

A crucial architectural point is that Home Food was not designed as one monolithic app for everyone.

There were two Android applications:

Provider App
    +
Customer App

This separation allowed each application to optimize around a different workflow.

8. Provider Application

The provider application was designed for home cooks.

A typical flow was:

Splash
  ↓
Onboarding
  ↓
Phone / SMS Verification
  ↓
Provider Registration
  ↓
Management Approval
  ↓
Provider Dashboard
  ↓
Availability / Food Management
  ↓
Orders / Operations

The archived source and screenshots preserve evidence of the early provider build.

9. Provider Onboarding

The provider onboarding gathered substantial operational information.

The archived interface includes fields such as:

gender,
first and last name,
national ID,
cooking skill level,
IBAN / Sheba account,
bank card number,
landline telephone,
address,
referrer,
alias / display name,
email.

This is not ordinary consumer registration.

It is clearly a provider onboarding workflow.

10. Management Approval

Providers were not immediately activated.

The workflow included an administrative approval stage.

Conceptually:

Provider Applies
      ↓
Profile / Identity Data
      ↓
Management Review
      ↓
Approved
      ↓
Provider Access

The surviving UI explicitly confirms that provider data had to be approved by site management before full application access.

This is an important marketplace trust mechanism.

11. SMS Authentication

The archived source contains a real SMS-based login flow.

Known endpoints include:

https://homefood.ir/smsService.php?tel=

and:

https://homefood.ir/isValidCode.php?tel=...&code=...

The Android application used network requests to:

submit a phone number,
trigger SMS code delivery,
receive the user-entered verification code,
validate that code against the backend.

This confirms that the application was connected to a real backend rather than operating as a static prototype.

12. Provider Availability

One of the most important business features was time-based provider availability.

Home cooks could specify:

when they were available to cook,
and therefore when their food could participate in the marketplace.

This solves a critical difference between restaurants and home cooks.

A home cook may not operate:

08:00–23:00
Every Day

Instead, availability may be:

Monday      12:00–15:00
Tuesday     Not Available
Wednesday   18:00–21:00
...

The platform needed to model supply as dynamic rather than permanently open.

13. Food Capability Selection

The provider could specify what foods they were able to prepare.

Importantly, the workflow was designed to minimize typing.

Instead of forcing users to manually enter long food names repeatedly, the system used a selection-oriented interface.

Conceptually:

Available Food Catalog
        ↓
Provider Selects
        ↓
Provider Menu / Capabilities

This is a strong UX decision for non-technical users.

14. Why Selection-Based Input Matters

The target provider population included ordinary home cooks rather than professional marketplace administrators.

Therefore, reducing typing friction mattered.

A selection-driven model improves:

onboarding speed,
consistency,
spelling normalization,
food categorization,
discoverability,
and backend data quality.

It also makes matching customer demand against provider capability easier.

15. Provider Dashboard

The surviving early provider dashboard shows several operational areas.

Known functionality includes concepts such as:

adding food,
food/menu list,
training,
daily list,
recent comments,
home/dashboard,
management messaging,
profile.

The dashboard also displayed marketplace metrics such as:

recent balance,
ranking among users/providers,
score/rating.

This confirms that the provider application was more than a simple “publish food” form.

It was an operational workspace.

16. Provider Reputation

The system included provider-facing reputation indicators.

Examples visible in the archived UI include:

score,
ranking,
reviews/comments.

This creates a marketplace feedback loop:

Orders
  ↓
Customer Experience
  ↓
Ratings / Reviews
  ↓
Provider Reputation
  ↓
Future Customer Trust

17. Financial Visibility

The provider dashboard included financial information such as recent balance.

This aligned with a broader settlement process in which cooks could be paid according to defined settlement cycles.

Known settlement modes included:

weekly settlement,
monthly settlement,
and operational petty-cash / advance-style handling where applicable.

The exact accounting implementation should be described from source/accounting evidence if recovered later.

18. Customer Application

The customer application served the demand side of the marketplace.

Its core purpose was:

allow ordinary users to find and order fresh, available home-cooked food.

A simplified customer journey:

Open App
   ↓
Authenticate
   ↓
Browse Available Food
   ↓
View Food / Provider
   ↓
Choose Quantity
   ↓
Place Order
   ↓
Select Payment
   ↓
Delivery
   ↓
Rating / Review

19. Freshness as a Product Principle

The product was positioned around:

fresh food,
hot food,
home-prepared food,
and reduced dependence on preservatives or industrial food preparation.

The archived onboarding screens explicitly emphasize:

homemade food,
delivery,
organic/healthy positioning,
complete food,
and absence of preservatives / additives.

These screens formed the initial product narrative.

20. Onboarding UX

The provider build contains a four-screen onboarding flow implemented using:

ViewPager
TabLayout
a custom PagerAdapter
persisted first-run state

The four archived onboarding topics are:

Home-Cooked Food
Delivery Service
Home Food Benefits
Complete Food

The final screen exposes a “start application” action.

This is evidence of deliberate mobile UX design rather than a purely functional prototype.

21. First-Run Persistence

The onboarding flow stored a preference indicating that the intro had already been viewed.

Conceptually:

First Launch
    ↓
Show Onboarding
    ↓
Save Preference
    ↓
Later Launch
    ↓
Skip Onboarding

This is a small but important product detail.

22. Customer Food Discovery

The marketplace needed to show food that was actually orderable.

The visible customer-side asset set indicates support for concepts such as:

food cards,
ratings,
quantity controls,
food details,
order history,
delivery address,
and instructional/content pages.

The exact final customer build should be reconstructed from the separate customer application archive if available.

23. Order Flow

The core business transaction was:

Customer
   ↓
Selects Available Meal
   ↓
Places Order
   ↓
Order Routed to Marketplace
   ↓
Provider Prepares Meal
   ↓
Courier Pickup
   ↓
Customer Delivery

This is a real fulfillment workflow, not merely marketplace discovery.

24. Delivery / Last-Mile Fulfillment

Delivery was part of the business model from the start.

The platform did not simply connect users and leave logistics entirely unmanaged.

The intended service promise was:

hot, fresh home food delivered to the customer.

This required a pickup-and-delivery chain:

Cook
  ↓
Courier
  ↓
Customer

Initial operational support leveraged existing food-delivery logistics associated with the Snappfood ecosystem.

Later logistics arrangements evolved separately.

25. Payment Flexibility

The platform supported multiple payment approaches rather than assuming a single method.

The user describes the system as supporting the required payment modes for marketplace operation.

Because exact processor/gateway details have not yet been reconstructed from source, the public description should use:

multiple customer payment flows

rather than naming an unverified payment provider.

26. Provider Settlement

Customer payment and provider settlement were separate business concerns.

Providers could be settled according to operational cycles such as:

weekly,
monthly,
and advance / petty-cash arrangements.

Conceptually:

Customer Payment
       ↓
Marketplace Accounting
       ↓
Commission / Adjustments
       ↓
Provider Balance
       ↓
Settlement Cycle
       ↓
Cook Payment

This is a major distinction between a simple ordering app and a marketplace platform.

27. Administrative Back Office

The existing administration environment was based on WordPress.

The WordPress platform predated the Android applications and had existed since approximately 2016.

It was not originally developed by me.

This ownership boundary is important.

28. Existing WordPress Marketplace Layer

The archived APK contains evidence of an endpoint:

https://homefood.ir/wp-json/dokan/v1/stores/

This indicates integration with a WordPress / Dokan-style multi-vendor marketplace layer in at least one application build.

However, the existing API did not provide the quality or flexibility required by the Android platform.

29. Custom API Layer

A major engineering contribution was creating a custom API layer around the existing backend/database.

The existing APIs were insufficient for the mobile workflow.

Rather than accept those limitations, I implemented my own API access layer so the mobile applications could obtain the required marketplace data.

The architectural situation was:

Existing WordPress / Marketplace Database
              │
      Existing API — Insufficient
              │
              X
              │
        Custom API Layer
              │
       Android Applications

This is a strong example of integration engineering.

30. Why the Custom API Mattered

The mobile applications needed reliable access to operational data.

Typical marketplace data includes:

providers,
food listings,
availability,
users,
orders,
balances,
ratings,
and administrative state.

If the existing API does not expose the correct model, the mobile client becomes difficult or impossible to implement cleanly.

The custom API effectively became an adaptation layer between:

Legacy / Existing Backend

and:

New Mobile Product

31. Legacy Backend Modernization Pattern

This is the same architecture pattern seen in many enterprise projects:

Existing System
      ↓
Do Not Replace Immediately
      ↓
Build Integration / API Layer
      ↓
Expose Required Capabilities
      ↓
Develop New Clients

In Home Food:

Existing WordPress Marketplace
      ↓
Custom API
      ↓
Two Android Apps

That makes the project relevant beyond consumer mobile development.

32. Android Technology Stack

The archived provider source confirms:

Java
Android SDK
compileSdkVersion 28
targetSdkVersion 28
Android Support Libraries 28
AppCompat
Design Support Library
ConstraintLayout
RecyclerView
ViewPager
TabLayout
Volley 1.1.1
Gson 2.8.2
JUnit 4.12
Espresso test dependency
Gradle-based Android project structure

The exact customer-app snapshot may contain additional libraries.

33. Networking

The archived provider application uses Volley for network requests.

This supported operations such as:

SMS request,
verification code validation,
backend communication.

The presence of Gson indicates JSON/object serialization support in the project stack.

34. RTL / Persian UX

The application was built for Persian-speaking users.

The archived Android manifest explicitly enables RTL support.

The project also includes multiple Persian font files with different weights.

This indicates deliberate control over:

Persian typography,
RTL layout,
localized user experience,
and visual consistency.

35. Custom Persian Fonts

Archived font assets include variants such as:

iran.ttf
iranbold.ttf
iranlight.ttf
iranmedium.ttf
iranultralight.ttf

This gave the application a more intentional visual identity than default system typography.

36. Branding

Home Food had a distinct visual identity.

The logo combines:

a chef-hat symbol,
Persian “هوم فود” branding,
Latin “HOMEFOOD” text,
green as the primary brand color,
and red as a secondary food-oriented accent.

The splash and onboarding screens also use food photography and large whitespace to establish a clean consumer-food aesthetic.

37. Splash Screen

The archived splash screen presents:

Home Food logo,
white minimalist background,
food imagery arranged along the bottom.

This creates immediate recognition before entering onboarding/authentication.

38. Early Build vs. Final Product

The surviving screenshots represent the first build / early UI generation.

That distinction matters.

The project later evolved beyond this initial visual state.

Therefore:

early screenshots are evidence of functionality and evolution,
they should not automatically be presented as the final UX,
and the portfolio can explicitly label them as early-build artifacts.

39. RecyclerView-Based Provider Interface

The provider application eventually entered a RecyclerView-oriented operational interface.

The early dashboard demonstrates a mobile management view rather than a static website wrapper.

The provider could interact with platform functions from a native Android client.

40. Management Messaging

The provider navigation includes messaging to management.

This supports a communication channel between:

Provider
   ↕
Marketplace Management

Useful for:

support,
operational issues,
approvals,
disputes,
and provider coordination.

41. Reviews and Comments

The provider application included access to recent reviews/comments.

This is important because reputation is not hidden exclusively on the customer side.

Providers could monitor feedback.

This creates:

Customer Feedback
        ↓
Provider Awareness
        ↓
Quality Improvement / Reputation

42. Training / Educational Content

The provider dashboard also included training-oriented content.

This suggests the platform was designed not only to transact but also to support providers with educational material.

Potential purposes included:

food preparation guidance,
quality expectations,
platform operation,
and provider development.

The exact final content should be documented from surviving data if recovered.

43. Telegram Notification Integration

One unusual requirement was that the target environment could not rely on Firebase push notifications as originally expected.

Instead of blocking the system on that dependency, an alternative path was implemented using Telegram bot integration.

Conceptually:

Marketplace Event
      ↓
Notification Service
      ↓
Telegram Bot
      ↓
Operational Notification

This demonstrates pragmatic adaptation to infrastructure constraints.

44. Why Telegram Integration Matters

The significance is not Telegram itself.

The engineering value is:

when a preferred external service was unavailable, the notification workflow was redesigned around an accessible alternative rather than allowing the product to fail.

This is a good example of constraint-driven engineering.

45. Notification Architecture

A simplified conceptual model:

Order / Operational Event
          ↓
Backend
          ↓
Notification Decision
          ↓
Available Channel
     ┌────┴────┐
     ↓         ↓
App Push    Telegram Bot
(where usable)

The precise final routing should only be described after the backend source is recovered.

46. Production Delivery

This project was not abandoned as a prototype.

The complete system—including Android applications and backend integration—was delivered to the customer.

The platform was launched and operated for multiple years.

This substantially strengthens its portfolio value.

47. Business Outcome

The business eventually ceased for non-technical organizational reasons.

The portfolio should not include private personal details about the customer’s management circumstances.

The professional statement is sufficient:

The platform operated for several years before the business was discontinued due to non-technical organizational circumstances.

48. My Role

My role covered the technical delivery of the mobile marketplace layer and integration with the pre-existing backend.

Confirmed responsibilities include:

understanding the marketplace workflow,
designing the Android user experience,
building provider-side Android functionality,
building customer-side Android functionality,
splash and onboarding design,
SMS authentication integration,
provider registration workflow,
management-approval flow,
provider operational dashboard,
marketplace API integration,
designing and implementing a custom API layer over the existing database/backend,
integrating WordPress marketplace data,
implementing network communication,
handling Persian / RTL UX,
supporting provider and customer marketplace workflows,
integrating alternative Telegram-based notifications,
and delivering the mobile/backend-integration solution to the customer.

The pre-existing WordPress site itself was not originally developed by me.

49. Ownership Boundary

This distinction should be explicit:

Not originally mine

original WordPress platform
original WordPress setup dating from approximately 2016
initial backend marketplace implementation

My technical contribution

Android marketplace applications
mobile UX
backend/mobile integration
custom API layer
SMS authentication integration
marketplace workflow implementation
notification adaptation
production delivery

This boundary increases credibility.

50. System Architecture — V1

A defensible reconstruction:

                    ┌──────────────────────┐
                    │   WordPress Admin    │
                    │ Management / Control │
                    └──────────┬───────────┘
                               │
                               ↓
                 ┌─────────────────────────┐
                 │ Existing Marketplace DB │
                 │ WordPress / Dokan Layer │
                 └──────────┬──────────────┘
                            │
             Existing API   │
             insufficient   │
                            ↓
                  ┌──────────────────┐
                  │ Custom API Layer │
                  └───────┬──────────┘
                          │
             ┌────────────┴────────────┐
             │                         │
             ↓                         ↓
 ┌────────────────────┐     ┌────────────────────┐
 │ Provider Android   │     │ Customer Android   │
 │ App                │     │ App                │
 └──────────┬─────────┘     └──────────┬─────────┘
            │                          │
            ↓                          ↓
 Provider Availability             Browse / Order
 Food Capability                   Payment
 Orders                            Delivery
 Balance / Rating                  Rating
            │                          │
            └──────────┬───────────────┘
                       ↓
                Order Fulfillment
                       ↓
                    Courier

51. Authentication Architecture

The early provider build shows:

Phone Number
    ↓
SMS Service Endpoint
    ↓
Verification Code
    ↓
Validation Endpoint
    ↓
Provider Registration / Login

This is a practical passwordless-style authentication model for mobile users.

52. Provider Lifecycle

New Provider
    ↓
SMS Verification
    ↓
Profile Registration
    ↓
Bank / Identity Details
    ↓
Management Approval
    ↓
Food Capability Selection
    ↓
Availability Setup
    ↓
Marketplace Active
    ↓
Orders
    ↓
Ratings / Balance / Settlement

This is a complete provider lifecycle.

53. Customer Lifecycle

New Customer
    ↓
Registration / Authentication
    ↓
Discover Available Food
    ↓
Select Meal
    ↓
Order
    ↓
Payment
    ↓
Courier Fulfillment
    ↓
Delivery
    ↓
Rating / Review

54. Order Lifecycle

A conceptual order-state model:

Created
  ↓
Accepted / Confirmed
  ↓
Preparation
  ↓
Ready for Pickup
  ↓
Courier Pickup
  ↓
In Delivery
  ↓
Delivered

The exact historical state names should be verified from the final backend/source if recovered.

55. Settlement Lifecycle

Delivered Orders
      ↓
Provider Earnings
      ↓
Marketplace Accounting
      ↓
Balance
      ↓
Settlement Rule
  ┌──────┼───────┐
  ↓      ↓       ↓
Weekly Monthly Advance/
               Petty Cash

This demonstrates actual marketplace operations rather than a simple catalog app.

56. Why Home Food Is Architecturally Interesting

The system combines several concerns that are often separate:

two-sided marketplace,
native mobile clients,
identity verification,
provider approval,
dynamic supply availability,
food catalog,
ordering,
payment,
provider accounting,
delivery,
reputation,
admin oversight,
notifications,
and legacy backend integration.

That makes the project much more substantial than its early screenshots may suggest.

57. Business Process Digitalization

The project digitized a real offline process:

Home Cook Has Capacity
      ↓
Customer Wants Meal
      ↓
Order Match
      ↓
Cooking
      ↓
Pickup
      ↓
Delivery
      ↓
Settlement

The software coordinated the actors around that chain.

58. Dynamic Supply

Unlike a restaurant with a predictable menu, home cooks have variable:

schedules,
capacities,
dishes,
and availability.

Therefore the marketplace needed to model dynamic supply.

This is a core product-design difference.

59. Marketplace Trust

The system incorporated several trust mechanisms:

management approval,
provider identity/profile data,
ratings,
reviews,
provider scoring/ranking,
management communication.

These reduce the risk inherent in a marketplace where food is prepared in private homes.

60. Marketplace Economics

The platform needed to separate:

Customer Transaction

from:

Provider Settlement

This requires marketplace accounting logic.

Even if the original implementation was simpler than modern fintech platforms, the business model clearly contained this distinction.

61. Logistics Integration

The platform also separated:

Food Production

from:

Delivery Fulfillment

The cook prepared food.

A courier transported it.

The customer consumed it.

This division of responsibility is essential to marketplace scalability.

62. Management as Supervisor

Management was not intended to manually execute every order.

Its primary role was supervisory.

This is a better operating model than creating a system that depends on permanent manual intervention.

Management could oversee:

provider status,
user issues,
operational exceptions,
marketplace activity,
and financial concerns.

63. API Adaptation as a Strategic Decision

One of the strongest engineering decisions in this project was not trying to rewrite the entire existing WordPress business platform.

Instead:

Existing Backend
     ↓
Custom API Adapter
     ↓
Modern Mobile Clients

This reduced migration risk and accelerated delivery.

It is a classic modernization pattern.

64. Constraints

The project operated under real-world constraints:

inherited WordPress backend,
poor / insufficient existing APIs,
Android-era tooling,
Persian RTL UX,
mobile network reliability,
local SMS infrastructure,
push-notification limitations,
marketplace trust,
delivery coordination.

The system had to work around these constraints rather than assume ideal infrastructure.

65. Archived Source State

The surviving provider-source archive is not a clean final repository.

It contains:

Android source,
compiled APKs,
build artifacts,
Gradle metadata,
resources,
older and incomplete source snapshots.

Some Activity source files referenced by the manifest are absent from the current Java source tree, while compiled APK artifacts still preserve evidence that later/other classes existed.

One source file also contains an obvious accidental fragment of non-Java code.

Therefore the archive should be treated as:

historical evidence, not a clean reproducible final Git repository.

66. Surviving APK Evidence

The archive includes compiled application packages.

This is valuable because compiled artifacts preserve evidence beyond the incomplete source snapshot.

Known APK-era evidence includes:

SMS service endpoint,
verification endpoint,
WordPress/Dokan store endpoint.

This helps reconstruct the integration architecture.

67. Reproducibility Strategy

If reconstructing the historical V1:

preserve the current archive unchanged,
create a forensic copy,
inventory source vs. compiled classes,
decompile APKs where legally/appropriately possible,
recover missing resources/classes,
rebuild against historical Android toolchain,
document the original architecture,
only then begin modernization.

Do not overwrite the historical evidence with a modern migration.

68. Production Status

Professional status:

Launched production platform; operated for several years; later discontinued for non-technical business/organizational reasons.

This is materially different from a prototype.

69. Career Relevance

Recommended:

Tier A — CV Core / Featured Portfolio Project

Why:

real customer,
production launch,
multi-year operation,
two mobile apps,
multi-role marketplace,
custom API,
legacy integration,
fulfillment,
payments,
settlement,
notifications,
admin backoffice,
end-to-end business process.

This is strong evidence for senior application architecture and product engineering roles.

70. Career Evidence

The project provides evidence of:

Solution Architecture
Application Architecture
End-to-End Ownership
Mobile Engineering
Product Engineering
Marketplace Architecture
Legacy Modernization
API Integration
Business Process Digitalization
Payment / Settlement Workflow Design
Last-Mile Fulfillment
Authentication
Notification Integration
RTL / Localization
Production Delivery

71. Website Hero

Home Food — Two-Sided Home-Cooked Food Marketplace

Android · Java · Custom API · WordPress · Provider Marketplace · Delivery Fulfillment

Designed and delivered a production marketplace connecting approved home cooks with local customers. The platform included separate provider and customer Android applications, SMS authentication, provider approval and availability, food catalog management, customer ordering, multiple payment flows, courier fulfillment, provider settlement, ratings, WordPress-based administration, a custom API integration layer, and Telegram-based operational notifications.

72. Website Project Card

Home Food

Two-Sided Marketplace · Android · Custom API · Delivery · Payments

Built a production home-food marketplace connecting approved home cooks with customers through separate Android apps, dynamic availability, ordering, fulfillment, settlement, ratings, and a custom integration layer over an existing WordPress backend.

73. Short Website Card

Home Food Marketplace

A production two-sided home-food marketplace with provider/customer Android apps, custom API integration, ordering, delivery, settlement, reputation, and administrative workflows.

74. One-Line Description

Built and launched a two-sided Android marketplace connecting home cooks with customers, including availability, ordering, fulfillment, payments, settlement, ratings, and legacy WordPress integration.

75. CV Entry — Full

Home Food — Two-Sided Mobile Marketplace / Android / API Integration

Designed and delivered a production home-food marketplace connecting approved home cooks with local customers. Built separate Android provider and customer applications, SMS-based onboarding, provider approval and availability workflows, menu/food selection, customer ordering, multiple payment flows, courier fulfillment, provider balances and settlement cycles, reviews/ratings, and operational messaging. Integrated the mobile platform with an existing WordPress/Dokan backend by building a custom API layer when the legacy APIs proved insufficient, and added Telegram-bot notification support where Firebase push was unavailable. The platform launched and operated for several years.

76. CV Entry — Short

Built and launched a two-sided Android home-food marketplace with provider/customer apps, custom WordPress API integration, ordering, delivery, payments, settlement, ratings, SMS authentication, and Telegram notifications.

77. Architecture-Focused CV Entry

Architected the mobile/integration layer for a production two-sided marketplace, introducing a custom API adapter over a legacy WordPress/Dokan backend and supporting provider onboarding, dynamic availability, customer ordering, fulfillment, settlement, and alternative notification channels.

78. Interview Story — Situation

A customer had an existing WordPress marketplace foundation but wanted a real mobile home-food business connecting home cooks and consumers.

The existing backend APIs were not suitable for the mobile workflows.

The product also had operational constraints around:

provider trust,
dynamic availability,
delivery,
settlement,
and push notifications.

79. Interview Story — Task

Build the mobile marketplace layer and make it work with the inherited backend rather than forcing an immediate full backend rewrite.

The platform needed separate experiences for:

providers,
customers,
management,
and logistics.

80. Interview Story — Action

I built separate Android applications for home cooks and customers.

On the provider side I implemented:

SMS onboarding,
identity/profile registration,
administrative approval,
cooking availability,
food selection,
provider dashboard,
ratings/reviews,
balance/settlement visibility,
and management communication.

On the customer side, the system supported:

food discovery,
ordering,
payment,
delivery,
and feedback.

Because the existing WordPress/Dokan APIs were insufficient, I created a custom API layer to expose the marketplace data required by the mobile applications.

When Firebase push could not be used in the operating environment, I integrated Telegram-bot notifications as an alternative operational channel.

81. Interview Story — Result

The system was delivered to the customer, launched in production, and operated for several years.

The business later stopped for organizational reasons unrelated to the core technical delivery.

82. Technical Interview Version

“Home Food was not one food-ordering app; it was a two-sided marketplace. Home cooks registered, went through approval, selected the foods they could prepare and the hours they were available. Customers used a separate Android app to discover currently available home-cooked meals and place orders. Delivery picked the food up from the cook and delivered it to the customer. The existing management side was WordPress/Dokan, but its APIs were not sufficient for the mobile workflows, so instead of rewriting the entire backend I built a custom API layer over the existing data. We had multiple payment modes and provider settlement cycles, and when Firebase push was not usable in the target environment I integrated Telegram-bot notifications as an alternative. The product launched and ran for several years.”

83. Solution Architecture Interview Angle

The strongest architecture story is:

Integrate and adapt before replacing.

The inherited backend already contained valuable business data and administration.

Rewriting everything would have increased:

delivery time,
migration risk,
and operational disruption.

Instead:

Legacy WordPress/Dokan
        ↓
Custom API Adapter
        ↓
Native Android Marketplace

This is a reusable enterprise modernization pattern.

84. Product Engineering Interview Angle

Another strong story is the difference between:

Restaurant Marketplace

and:

Home-Cook Marketplace

A home cook has variable:

availability,
capacity,
menu,
and operating schedule.

Therefore supply must be modeled dynamically.

That product constraint directly influenced the software architecture.

85. UX Interview Angle

A strong UX decision was using selection-based input for the foods providers could cook.

Instead of requiring lengthy manual entry:

Type Dish Name
Type Category
Type Metadata

providers could choose from structured options.

Benefits:

less friction,
normalized data,
easier search,
fewer spelling differences,
faster onboarding.

86. Notification Resilience Story

Preferred dependency unavailable:

Firebase Push

Operational need remains:

Marketplace Notifications

Solution:

Alternative Notification Channel
        ↓
Telegram Bot

The important skill is dependency substitution under real constraints.

87. Modern V2 — Strategic Goal

A modern V2 should preserve the business model while replacing the legacy coupling.

Recommended direction:

API-First Marketplace Platform
        +
Modern Mobile Clients
        +
Dedicated Admin
        +
Event-Driven Notifications
        +
Structured Payments / Ledger
        +
Delivery Integration

88. Modern V2 Architecture

Possible architecture:

                   ┌─────────────────┐
                   │   Web / Admin   │
                   └────────┬────────┘
                            │
┌────────────────┐          │          ┌────────────────┐
│ Provider App   │──────────┼──────────│ Customer App   │
└────────┬───────┘          │          └────────┬───────┘
         │                  ↓                   │
         │          ┌─────────────────┐         │
         └─────────→│    API Gateway  │←────────┘
                    └────────┬────────┘
                             │
                    ┌────────┴────────┐
                    │                 │
                    ↓                 ↓
             Identity Service   Marketplace Core
                                      │
             ┌────────────────────────┼─────────────────────┐
             ↓                        ↓                     ↓
       Provider Service         Order Service         Catalog Service
             │                        │                     │
             ↓                        ↓                     ↓
       Availability             Fulfillment             Search
             │                        │
             ↓                        ↓
       Settlement              Delivery Adapter
             │
             ↓
       Payment / Ledger

89. Modern V2 — Suggested Stack

One modern implementation could use:

Backend

Laravel or Spring Boot
PostgreSQL
Redis
queues
object storage
REST / OpenAPI

Mobile

native Android / Kotlin
or Flutter if shared client delivery is a priority

Web / Admin

Laravel/Livewire
or Angular / React depending on architecture

Infrastructure

Docker
CI/CD
observability
centralized logging

The exact V2 stack should follow product goals rather than portfolio fashion.

90. Modern V2 — Identity

Modern identity could support:

OTP / SMS authentication,
device/session management,
refresh tokens,
rate limits,
suspicious-login protection,
provider verification states,
RBAC.

91. Modern V2 — Provider Verification

Provider onboarding should become an explicit state machine:

Draft
  ↓
Submitted
  ↓
Under Review
  ↓
Approved / Rejected
  ↓
Active / Suspended

This makes administrative state auditable.

92. Modern V2 — Availability Model

A structured availability model could include:

Provider
├── recurring schedule
├── exceptions
├── vacation dates
├── daily capacity
└── cutoff time

This is more robust than embedding availability directly into food listings.

Provider
  ↓
ProviderFood
  ├── FoodDefinition
  ├── price
  ├── capacity
  ├── preparation time
  ├── active status
  └── availability override

This separates:

What food exists?

from:

Can this provider sell it now?

94. Modern V2 — Order State Machine

Created
  ↓
Payment Pending
  ↓
Confirmed
  ↓
Provider Accepted
  ↓
Preparing
  ↓
Ready for Pickup
  ↓
Courier Assigned
  ↓
Picked Up
  ↓
Delivered

Failure paths:

Cancelled
Rejected
Payment Failed
Delivery Failed
Refunded

95. Modern V2 — Financial Ledger

Do not model marketplace money as a single mutable balance.

Use a ledger:

Ledger Entry
├── order revenue
├── platform commission
├── delivery fee
├── refund
├── adjustment
├── advance
└── settlement

Then:

Provider Balance = Sum(Ledger Entries)

This is safer and auditable.

96. Modern V2 — Settlement

Settlement could be configured per provider:

weekly,
monthly,
manual,
threshold-based.

Settlement states:

Pending
Approved
Processing
Paid
Failed

97. Modern V2 — Delivery Integration

Delivery should be abstracted through an adapter layer:

Order
  ↓
Delivery Service Interface
       │
       ├── Provider A
       ├── Provider B
       └── Internal Courier

This avoids hard-coding the marketplace to one courier company.

98. Modern V2 — Notification Service

A modern notification service could route:

Event
 ↓
Notification Service
 ├── Push
 ├── SMS
 ├── Telegram
 ├── Email
 └── In-App

Channels become configuration rather than core business logic.

99. Modern V2 — Observability

Production monitoring should include:

API latency,
failed logins,
OTP delivery failures,
order-state delays,
payment failures,
delivery delays,
notification failures,
provider acceptance rate,
cancellation rate.

100. Modern V2 — Security

Important controls:

strong API authentication,
rate limiting,
OTP abuse prevention,
authorization,
encryption in transit,
secure handling of financial data,
tokenized payment integration,
audit logs,
PII minimization,
secure admin access.

101. Modern V2 — Search and Discovery

Customer food discovery could include:

location,
available now,
category,
provider rating,
price,
preparation time,
dietary attributes,
delivery ETA.

Search should reflect current supply, not just static catalog data.

102. Modern V2 — Provider Quality

Potential quality controls:

approval workflow,
documentation checks,
rating thresholds,
suspension rules,
complaint handling,
fulfillment metrics,
hygiene / compliance metadata where legally required.

103. Modern V2 — Analytics

Management dashboard could include:

GMV,
order count,
active providers,
provider supply hours,
cancellation rate,
fulfillment rate,
repeat customers,
average order value,
settlement liabilities,
delivery performance.

104. Modern V2 — Data Migration

If rebuilding from surviving WordPress data:

Extract
  ↓
Normalize
  ↓
Map Legacy IDs
  ↓
Validate
  ↓
Import
  ↓
Reconcile

Preserve historical:

users,
providers,
products/foods,
orders,
ratings,
balances where available.

105. Modern V2 — Backward Compatibility

A transitional architecture could keep WordPress temporarily:

New Core API
   ↕
Legacy Adapter
   ↕
WordPress

Then migrate domain by domain.

This reduces big-bang risk.

106. Source Evidence Inventory

The surviving archive currently provides evidence for:

Android Gradle project,
provider application source,
multiple compiled APKs,
SMS endpoints,
onboarding flow,
RTL support,
provider registration,
admin verification,
provider dashboard,
Volley,
Gson,
WordPress/Dokan endpoint in APK,
visual assets,
Home Food branding.

Additional customer app/backend archives would strengthen reconstruction further.

107. Recommended Portfolio Screenshots

Best screenshots to show:

Home Food logo / splash
four onboarding screens
SMS verification
provider registration
management approval
provider dashboard
food catalog / RecyclerView
customer browse/order flow
order status / delivery
WordPress admin/API architecture diagram

Do not show broken backend states without labeling them as archival reconstruction.

108. Suggested Cover Direction

Square / portfolio cover:

Center: Home Food marketplace brand
Left: Home Cook / Provider App
Right: Customer App
Middle: Order / Delivery Flow
Background: API / Marketplace / WordPress integration
Bottom: Cook → Courier → Customer

Visual language:

clean white + green,
warm food photography,
mobile UI,
marketplace network,
modern delivery flow.

109. Suggested Categories

Primary:

Marketplace
Mobile
Product Engineering
Enterprise / Business Systems

Secondary:

API Integration
Legacy Modernization
Delivery / Fulfillment
Payments
RTL / Localization

110. Suggested Tags

Android
Java
WordPress
Dokan
Custom API
Volley
Gson
SMS Authentication
OTP
RecyclerView
ViewPager
TabLayout
RTL
Persian
Marketplace
Two-Sided Marketplace
Provider Onboarding
Home Food
Food Delivery
Last-Mile Delivery
Payments
Settlement
Ratings
Reviews
Telegram Bot
Legacy Integration
Product Engineering

111. Website Metadata

Page Title

Home Food — Two-Sided Home-Cooked Food Marketplace

Meta Description

A production two-sided marketplace connecting approved home cooks with local customers through separate Android apps, dynamic availability, customer ordering, payment and settlement workflows, courier delivery, ratings, custom WordPress API integration, and alternative Telegram notifications.

Suggested Slug

/home-food-marketplace

112. Evidence Boundaries

Safe to claim:

approximately 2018,
two Android applications,
provider and customer roles,
WordPress management backend already existed,
custom API layer created by me,
SMS authentication,
provider approval,
provider cooking-time availability,
food selection,
customer ordering,
multiple payment modes,
weekly/monthly provider settlement,
operational advance/petty-cash handling,
delivery/courier flow,
Telegram bot notification integration,
launched,
operated for several years,
final customer delivery completed.

Avoid claiming until additional evidence is reviewed:

exact active-user counts,
exact transaction volume,
exact revenue,
exact commission percentage,
exact courier provider contractual architecture,
exact customer-app tech version if not recovered,
exact final payment gateway,
exact number of providers/customers,
exact production SLA.

113. Final Portfolio Statement

Home Food was a production two-sided marketplace launched around 2018 to connect approved home cooks with local customers seeking fresh, hot, home-prepared meals. I built the mobile marketplace layer as separate Android applications for providers and customers, implemented SMS onboarding, provider approval, dynamic cooking availability, structured food selection, ordering, payment and settlement workflows, ratings, operational messaging, and delivery coordination. The existing WordPress/Dokan backend predated my work and exposed APIs that were insufficient for the required mobile workflows, so I created a custom API integration layer to access and adapt the marketplace data. When Firebase push notifications could not be used in the target environment, I added Telegram-bot integration as an alternative notification path. The complete solution was delivered, launched, and operated for several years before the business later ceased for non-technical organizational reasons.

114. One-Line Summary

Built and launched a two-sided Android home-food marketplace with custom legacy-backend integration, provider availability, ordering, delivery, payments, settlement, ratings, SMS authentication, and Telegram notifications.

115. Ultra-Short Portfolio Label

Home Food — Two-Sided Marketplace · Android · Custom API · Delivery · Payments

116. Why This Belongs in a Senior Portfolio

This project is strong because it demonstrates that the work was not limited to screen implementation.

It required coordinating:

Business Model
      +
Two User Populations
      +
Mobile Apps
      +
Legacy Backend
      +
Custom API
      +
Identity
      +
Payments
      +
Settlements
      +
Delivery
      +
Notifications
      +
Production Launch

That is a real application-architecture problem.

117. Strongest Career Narrative

The most useful professional story is:

I inherited an existing business backend that was not designed for the mobile marketplace experience the customer wanted. Instead of rewriting the entire platform, I built the mobile product around a custom integration layer, separated provider and customer workflows into dedicated Android applications, modeled dynamic home-cook availability, connected ordering to delivery and financial settlement, and delivered a platform that operated in production for several years.

118. Final Classification

Period: ~2018
Domain: Two-Sided Marketplace / Food Delivery
Original Status: Production / Launched
Architecture: Two Android Apps + Custom API + Existing WordPress/Dokan + Delivery / Payments
Primary Role: Mobile & Integration Engineering / End-to-End Marketplace Delivery
CV Relevance: Tier A — Core Portfolio Evidence

Tags: Android REST API WordPress