1Build your ideaAvailable · Remote · Vietnam-based
Ship at the speed of idea.
What used to need 3 devs, I ship with 1. AI-leveraged builder for founders who want it fast, cheap, and senior-grade.
1Build your idea
2Chuyển làm ITCourse · For career switchers · Waitlist open
From career switcher to shipping.
I switched lanes and learned to build. Now I’m packaging the exact path into a hands-on course for career switchers who want to ship real products with AI.
3My studioStudio · Tools I actually ship with
The studio behind the work.
The stacks, tools, and gear I lean on to ship fast — handpicked, battle-tested, and linked so you can build with the same kit.
01
Work in four languages.
粵
普
EN
Vi
02
Ideas into real products.
3 devs used to ship what 1 dev does today — with AI as leverage.
I drop in with founders. Working artifact in front of users in days. Senior quality, fraction of the headcount.
03
Six engagements. One bar: things that ship.
/ 01
MVP Development
Blank repo to live product in 4–8 weeks. Real users, real conviction.
/ 02
Product Prototyping
Working prototypes in days. From idea you can’t describe to one you can’t put down.
/ 03
AI Workflow Integration
Embed AI where it earns its keep. Less hype, more throughput.
/ 04
Team Setup & Execution
Small senior teams that ship. Hire, scope, sequence, run.
/ 05
Product Strategy
Find the wedge. Pick the one bet worth shipping — and the artifact that proves it.
/ 06
Mobile & App Development
Flutter, iOS, Android, and the native bridges between them. Built to ship, replaceable, store-ready.
04
Five projects, with the receipts.
See more in the CV.
/ W01 · 2024–26 · Singapore · Airport operations
Cabs@Changi — live taxi queues & arrivals
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
Superhood — what’s happening on your street
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
EMMA SG — multi-operator charging & payments
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
Jitsu Drive — last-mile driver app
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
ResQ Club — surplus food marketplace
Live on both storesSource: client-owned, private
- 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.
05
AI where it matters. Ignored where it doesn’t.
Rough order of magnitude from how I work — not a contractual guarantee. Real numbers depend on the project.
Idea → prototypeSpeed
~2wks
Team velocityThroughput
~2–3× faster
HeadcountCost
1dev, not 3
Cycle time · before / afterLive
BaselineWith AI leverage
06
Tell me what you’re building. Get a quote.
BRIEF · 001Live
60-sec quote07 You bring the idea.
You bring the idea.
I’ll ship it.
First call is 30 minutes. I’ll know inside of it whether we should work together.