Flutter & Mobile App Portfolio

/ W01 · 2024–26 · Singapore · Airport operations

Live on Google PlaySource: client-owned, private

Problem: A taxi driver at Changi picks a terminal to queue at blind. Choose wrong and you idle behind 60 cabs while another terminal has planes landing and nobody waiting — bad for the driver, and passengers queue for a cab that is parked two terminals away.
What I implemented: The Flutter app for Changi Airport Group — a live per-terminal board pairing the taxi queue length against inbound arrivals for all four terminals.
Flight arrival lists per terminal with live status, and an on/off-shift toggle that tracks a driver’s activity across pickups.
Background execution so a shift keeps tracking with the app minimised or the screen off — a foreground service on Android, background modes on iOS, with state restored after the OS kills the process.
Push notifications when a terminal is short of taxis, plus the operator announcements feed.
Technical decisions: Put the two numbers a driver actually decides on — cabs waiting and planes inbound — side by side on the home screen, so the choice takes one glance at a phone mounted on a dashboard. Shift tracking had to survive backgrounding: a phone sits in a mount with the screen off for most of a shift, and an app that only counts while it’s in the foreground would ask someone mid-drive to keep it open. Shift state stays explicit rather than inferred from location, so the app never tracks a driver who is off the clock.

/ W02 · 2020–22 · Finland · Hyperlocal social

Live on both storesSource: client-owned, private

Problem: Local news, events and neighbour-to-neighbour notices — a lost dog, a road closure, a new bakery — live scattered across closed groups and algorithmic feeds. There was nowhere that just showed you what was happening where you actually are.
What I implemented: The Flutter app — map-based area selection, including free-hand drawing of a neighbourhood boundary rather than picking from fixed postcodes.
An aggregated feed pulling local news, events and offers from many sources into one chronological view, with per-topic filters.
Topic-scoped push notifications and a no-signup onboarding path.
Technical decisions: Let people draw their own area instead of snapping to administrative boundaries — a neighbourhood is where you actually walk, and it rarely matches a postcode. Kept the feed chronological rather than ranked, because the whole point is not losing a road closure to an engagement score. Onboarding works with no account, so following a street costs one swipe.

/ W03 · 2024–26 · Singapore · EV charging

Live on Google PlaySource: client-owned, private

Problem: Singapore’s EV charging network is split across several operators, each with its own app. Finding a working charger, starting a session and paying meant switching apps mid-trip.
What I implemented: The Flutter app for iOS and Android — charger discovery on a native map, session activation, and session history.
In-app payments and the authenticated account flow around them.
Push notifications for session state, plus the CI/CD pipeline that builds and ships to the stores.
Technical decisions: Normalised every operator behind one charger model so adding a network is a data change rather than a UI change. Used the platform map SDKs instead of a Flutter-only map, because charger clustering and live status at city scale need the native renderer to stay smooth.

/ W04 · 2023–24 · US · Logistics

Live on both storesSource: client-owned, private

Problem: The company’s existing driver app carried enough architectural debt that new delivery features were slow and risky to add — on the app drivers depend on for every shift.
What I implemented: Led the full Flutter rebuild of the mobile app, from the Riverpod state architecture up.
Driver onboarding, route browsing and the delivery workflow end to end.
Deep links into specific routes and packages, push notifications, and the release pipeline.
Technical decisions: Rebuilt on Riverpod so delivery state was explicit and testable rather than threaded through the widget tree — a driver mid-route can’t afford ambiguous state. Treated deep links as first-class entry points so a dispatch notification lands on the right screen with the app cold.

/ W05 · 2020–22 · EU · Food rescue

Live on both storesSource: client-owned, private

Current App Store listing — redesigned since the 2020 build.

Problem: Restaurants across Europe throw out sellable surplus at closing time. The app had to make buying it feel like ordinary takeaway — nearby, in stock right now, paid for before you walk over.
What I implemented: The Flutter app across multiple European markets, still on both stores today.
Live availability on Firebase Realtime Database — surplus counts change by the minute.
Native maps on both platforms (Google Maps on Android, Apple Maps on iOS) and in-app payments.
Technical decisions: Used Realtime Database rather than a polled REST endpoint because stale portion counts are the one bug that makes the product useless —a user walking to a sold-out pickup doesn’t come back. Used each platform’s own map instead of one cross-platform widget so directions hand off to the map app the user already trusts.

Product engineer who ships to app stores.