Ride hailing

Rider app: request a trip, see fare estimate, live trip, payment, rating. Driver app: go online, receive requests, navigate, complete trip, earnings. Admin: zones, pricing, driver approval, trip monitoring, support tools.

Location is central — map display, driver position updates, estimated arrival time, and trip status that cannot disagree between rider and driver screens.

Rider requests → matching → driver assigned → driver en route to pickup → arrived → trip started → en route to dropoff → completed → payment settled → rating. Cancel and no-show paths are defined up front so server and both apps handle them the same way.

Trip status is the contract. I document every transition, who triggers it, and what each app shows before screens are built. The server team implements the same status list; mobile shows only those statuses.

I lead mobile and full-stack work on live platforms at DSSI (Diverse System Solution Inc.) in the Philippines — food delivery, ride hailing, logistics, booking, e-commerce, and member portals. The flows and notes below come from that production work.

dexterbanastao.com is my portfolio and hire-me lane. For the company behind most of this delivery, ride, and commerce software, see dssi.international — context in the DSSI blog post.

I don't jump straight to screens. Every build starts with a process flow — who does what, in what order, and what status everyone sees at each step. That becomes the shared map for you, me, the server team, and testing.

Typical sequence: discovery call → list of roles and features → you sign off on the process flow → backend connection plan → mobile and web screens per role → connect everything → App Store or web launch → handoff notes. AI speeds up first drafts at each step; your sign-off stays human.

You get visibility at each step — not a black box and a surprise at launch.

For production mobile I use Framework7 and Cordova — one codebase that becomes apps in the Apple App Store and Google Play, with native features (camera, GPS, push notifications, file upload) where the product needs them.

I usually split by role: customer app, merchant or provider app, rider or courier app, and sometimes a lightweight admin app. Each role sees the right screens; all roles read the same order or job status from the server.

Before store submission I test on real phones — cold start, background resume, location permissions, and slow network on the paths that matter for your business.

I'm not siloed on mobile while the server team guesses what data each screen needs. I lead with the signed process flow and a written backend connection plan — who can do what, each status name, and what data each screen expects.

What the server team receives: a status diagram (order, trip, booking, or shipment steps), examples of data in and out, which role calls which function, and what happens when login fails or a step is invalid. PHP and MySQL on the server; secure database access; handlers that match what mobile and web already built against.

During build I review server changes for mismatches — renamed fields, missing statuses, login gaps — before testing wastes a week. When the plan must change, we update mobile and server in the same sprint. That coordination is how multi-role platforms stay in sync in production.

On solo or lead work I own mobile, the server connection plan, and often the PHP layer behind it. AI-assisted workflow means clear project rules in the repo — how screens should look, how the server should respond, security boundaries — plus repeatable playbooks for adding a screen or a payment step.

AI drafts mobile pages, server boilerplate, and PHP logic from the signed process flow. I review every change for security, plan alignment, and store rules before release. Other developers on the project get the same rules so output stays consistent.

Fast first drafts, careful launch — whether the product is delivery, booking, or a member portal. See AI engineering and AI engineer services.