Architecture, stack, key decisions and the quality gates DEV3 Sundrio passed before release.
The engineering behind Sundrio: a bag that pays several partners at once and refunds one part without touching the rest, deadlines enforced on read, and one driver queue that can stack two drops.
The problem it solves
A super app is five products that must agree on money. A customer fills one bag from a kitchen and a shop and pays once, but each partner owes its own order, its own commission and its own refund. A rider on a bike may carry a food drop and a grocery drop that lie on the same way, while a ride, a parcel and a home visit use the same wallet, the same Coins and the same Pass. Stock runs out, drivers accept at the same instant, a switch is flipped mid-checkout and a card payment can arrive after its hold has expired.
Architecture and approach
Sundrio is a Laravel 12 application with a Filament 4 admin at /admin, a public website, a customer web account at /account, a partner console at /partner and a REST API used by three Flutter apps.
One bag, many orders
The bag holds a section per partner. A quote prices each part and gives one total, one payment is taken for the whole bag, and each part becomes its own order that is tracked and settled separately. A part that a partner rejects or that runs out is refunded for that part only, Coins and promo shares shrink with it, and the parts always add up to what was paid.
Deadlines on read
Checkout holds, driver offers, partner accept timeouts and Pass periods are applied under a lock whenever a record is read or acted on, so correctness does not depend on the scheduler. A tick command only catches records nobody is looking at and retries refunds.
Money
Money is stored in integer cents. Refunds are written as a pending row inside the money transaction and sent after it commits. Every lock is taken through one ordered entry point, and a test records the order of the locking statements.
One driver queue
A ready order creates one queued job and offers go to nearby eligible drivers. A bike may take a second drop only if both fit its box and the second is within a set bearing and distance of the first. Service switches are read again inside the money transaction, so a switch flipped mid-checkout wins.
Apps
The customer, partner and driver apps share one API contract with the server, show countdowns from a measured clock offset, and start in a demo mode that needs no server.
Quality gates and results
Sundrio 1.0.0 ran 339 Pest tests and a browser and race smoke that passed once, both before a few small final edits. The installer test and the secret scan passed on the final zip. The full release-gate run was not repeated on the final code. The customer, partner and driver apps passed 136, 74 and 108 tests and their builds passed. The home page measured 90 performance and 100 for accessibility, best practices and SEO in a mobile Lighthouse run during the build.
Limits are listed on the item page: the demo data is smaller than planned, Stripe refunds have no idempotency key, Pass renewal by saved card needs a finished charger, the apps poll about every 5 seconds with no push notifications, GPS was not run on a device and the apps were tested on simulators only.
Tech stack
| Area |
Technologies |
| Application |
Laravel 12, Filament 4, Blade, REST API with OpenAPI |
| Services |
Eat, Mart, Ride, Send, Home, Service switches |
| Money |
One bag, one payment, Part refunds, Coins and Pass, Wallet and cash |
| Apps |
Flutter customer app, Flutter partner app, Flutter driver app, Shared dev3 Flutter package, Demo mode |
| Quality |
Pest, Static analysis, Browser and race smoke, Ledger check command |
Inside the build
Hero — A real photo of the city at dusk, the headline and one flat Service Wheel; the copy sits on a scrim.
Five services — Eat, Mart, Ride, Send and Home as one engraved strip with a colour each.
