Food delivery
Ordering apps are never just one screen — merchants, dispatch, payments, and tracking all have to agree.
Expertise

Features & roles
Food delivery is multi-role by default. Consumer browses menus and tracks orders. Merchant manages menu, accepts or rejects, and marks ready. Rider or driver gets dispatch, navigation, and proof of delivery. Admin or ops handles disputes, promos, zones, and reporting.
Core features: restaurant discovery, menu and modifiers, cart and checkout, payment handoff, order status timeline, live or staged tracking, ratings, notifications, and merchant onboarding. Marketplaces add commission and payout views on admin.
End-to-end process flow
Customer places order → merchant accepts (or auto-accept) → kitchen prepares → ready for pickup → rider assigned → rider en route → picked up → delivered → completed → payout and rating. Each step is a status backend and all apps must agree on.
I draw this flow with the client first, then map statuses to API fields and Framework7 screens. Dispatch rules (manual vs auto, batch vs single) change per product — the flow diagram is where we lock that before anyone writes PHP or Cordova code.
How I run the project (workflow)
I don't jump straight to screens. Every build starts with a process flow — who does what, in what order, and what status the system shows at each step. That flow becomes the shared map for you, me, backend devs, and QA.
Typical sequence: discovery call → role and feature matrix → process flow sign-off → API contract draft → mobile build per role → integration passes → store or web release → handoff notes. AI speeds drafting at each step; sign-off stays human.
You get visibility at each gate — not a black box and a surprise at launch.
Mobile implementation — Framework7 & Cordova
Production mobile for these products is Framework7 plus Cordova — one JavaScript codebase for iOS and Android, native plugins where the product needs camera, GPS, push, or file upload.
I usually split by role: consumer app, merchant or provider app, rider or courier app, and sometimes a lightweight admin mobile surface. Same API layer pattern in each — auth token, role guard, API module, status-driven screens that match the process flow we agreed on.
Framework7 handles routing, lists, forms, modals, and pull-to-refresh patterns that feel native enough for delivery and booking products. Cordova wraps it for the stores. I map each process-flow step to a screen or state so backend devs and QA know exactly what mobile expects at each status.
Before store submission I run device passes on real phones — cold start, background resume, location permissions, and offline or slow-network behavior on the paths that matter for your product.
Guiding backend developers on the same process flow
I'm not siloed on mobile while backend guesses endpoints. I lead with the process flow and a written API contract — roles, status enums, request and response shapes, and error codes the apps already handle.
What I hand backend devs: a status diagram (order/trip/booking/shipment states), JSON samples per endpoint, which role calls which route, and what happens on 401 or invalid transitions. PHP and MySQL on the server side; PDO with prepared statements; thin handlers that match the contract mobile already built against.
During build I review backend PRs for contract drift — field renames, missing statuses, auth gaps — before mobile QA wastes a week. When the contract must change, we version it and update mobile in the same sprint. That coordination is how multi-role platforms stay in sync in production.
Full stack delivery with AI engineering
On solo or lead full-stack work I own mobile, API shape, and often the PHP layer behind it. AI engineering means Cursor rules in the repo — Framework7 patterns, Cordova plugin usage, API client conventions, security bans — plus skills for recurring tasks like new screens or endpoints.
AI drafts Framework7 pages, API boilerplate, and PHP handlers from the signed-off process flow. I review every diff for security, contract alignment, and store rules before merge. Fellow devs get the same rules and contract doc so AI output stays consistent across the team.
Fast drafts, careful release — whether the product is a delivery app, booking platform, or member portal. See AI engineer services or the blog posts on React Native rules and PHP backends for the same discipline on other stacks.
FAQ
Questions I get asked
Can you build something like the big delivery apps?
The building blocks — multi-role portals, dispatch, tracking, payments — yes. Timeline and budget depend on how much you need on day one vs phase two.
Do you document the order flow before coding?
Yes — process flow and status diagram first, then API contract, then Framework7 screens per role. That is how merchant, rider, and consumer apps stay aligned with PHP on the backend.
Do you use Framework7 and Cordova in production?
Yes — that is my production mobile stack for multi-role delivery, ride, booking, and logistics products. One JavaScript codebase for iOS and Android, with store publishing when the product is ready.
How do you guide backend developers on the same product?
Process flow and API contract first — status enums, JSON samples, role permissions — then parallel mobile and PHP work. I review backend changes for contract drift before QA so apps and server stay aligned.
Where does AI fit in full-stack delivery?
AI drafts Framework7 screens, API boilerplate, and PHP handlers from the signed-off flow. Cursor rules keep patterns consistent; I review every diff for security and contract alignment before release.
Do you work with teams outside the Philippines?
Yes. I'm based in the Philippines and work with local teams and remote clients. English is fine, and I'm used to coordinating across time zones on production teams and direct collaboration.
Related