Caramove

Category: Marketplace
Platform: Mobile, PWA
Year: 2026; Built
Developer: Jaymark
Stat: 117; API endpoints
Stat: 4; roles, 4 separate auth guards
Stat: 26; mobile screens

Preview

iPhone & Android

A local delivery marketplace for Tuguegarao City. Customers, shop owners and riders each get their own experience inside one Flutter app, backed by a Laravel API and a Next.js admin panel — covering the whole order lifecycle from browsing a shop to a rider submitting photo proof of delivery.

What's Included

Browse shops and products, search, cart and checkout
Live shipping quote before the order is placed
Shop owner order queue: accept, prepare, mark ready
Rider assignment — automatic, with manual override
Order tracking on an OpenStreetMap view
Photo proof of delivery, then customer confirmation
Ratings and reviews once an order completes
Push notifications on every status change
Admin panel for shop approvals, reports and payouts
Rider incentives tracked, approved and marked paid

The Problem

Local deliveries in Tuguegarao City run on Facebook posts and phone calls. Shops and riders coordinate by hand, and customers have no idea where an order is once they've paid. Caramove puts all four parties — customer, shop owner, rider and admin — on one system, so an order moves through a single tracked lifecycle instead of a group chat.

By the Numbers

117
API endpoints
4
roles, 4 separate auth guards
26
mobile screens
~14,800
lines of Dart
18
Eloquent models, 30 migrations
3
client surfaces on one API

Under the Hood

Highlight 01
Four roles, four separate auth guards
Rather than one users table with a role column, each role has its own model, table and Sanctum guard. A customer token is structurally incapable of reaching a shop owner endpoint — authorisation is enforced by middleware that type-checks the authenticated model, so a missed permission check fails closed instead of leaking data.
Highlight 02
The order lifecycle is a state machine, not controller code
Every transition — accept, reject, prepare, ready, assign rider, dispatch, deliver, confirm, cancel — lives in one service with sixteen guarded methods. Controllers only call into it. Each transition also fires the right push notification to whichever party needs to know, so notifications can’t drift out of sync with order state.
Highlight 03
Shipping priced from configurable tiers
Instead of hard-coded rates, the quote engine composes weight tiers, distance tiers and peak-hour surcharges — flat or percentage, including windows that run past midnight — plus optional priority-delivery and rider-incentive settings. Operations can retune pricing from the admin panel without a deploy.
Highlight 04
Networking built for patchy mobile data
One shared Dio client attaches the auth token and retries timeouts, dropped connections and 5xx responses three times on a 3/6/10-second backoff. The API answers every error — 500s included — as JSON, so the app and admin panel parse one predictable error shape instead of occasionally choking on an HTML stack trace.
Highlight 05
Service-area enforcement
Delivery addresses are geofenced to Tuguegarao City before an order is accepted, keeping the rider pool inside a distance the shipping tiers were actually priced for.
Highlight 06
OpenStreetMap over Google Maps
Maps run on flutter_map against OSM tiles. For a single-city service area, Google’s tile costs and billing setup bought nothing, and dropping the dependency kept the app buildable without a paid API key.

Information