Feature-first architecture
The Flutter codebase is organised by feature — account, search, tutor, transaction, dashboard — rather than by layer, so each screen's pages, models, and state sit together and the app stays navigable as features grow.
Case · Mobile · Web · EdTech
MyClaaz
The Flutter and Vue front end for a Malaysian tutor marketplace that reached 15,000+ members (2021) across web, iOS, and Android.
Problem
A two-sided tutor marketplace lives or dies on its phone experience: discovery, scheduling, and payment all have to feel effortless.
My role
Front-end engineer (freelance) — Flutter app + Vue 2 web
Result
Shipped the iOS + Android app and the web front end for a platform that reached 15,000+ members and 14,000+ transactions across 20+ countries (per 2021 press).
01The problem
MyClaaz is a Malaysian EdTech marketplace that connects students with tutors and trainers, founded by Islamic-finance scholar Dr Zaharuddin Abdul Rahman; the platform was a recipient of Cradle Fund start-up assistance. As the freelance front-end engineer, I built the client side — the Flutter app for iOS and Android, and the Vue 2 web front end — against an API owned by the backend developer. A marketplace only works if finding a tutor, booking a slot, and paying all feel simple on a phone, so the front end had to carry discovery, scheduling, media, and payments without friction.
02A look at the app
03What I built
- Built the iOS and Android app in Flutter (Dart) — onboarding, account and PIN login, tutor search, profiles, scheduling, and the purchase flow's client side — across 126 source files in a feature-first architecture.
- Built the customer-facing web front end in Vue 2 against the same backend API.
- Location-based tutor discovery on Google Maps, with subject, distance, date, and duration filters.
- In-app scheduling on a calendar, plus the booking and purchase screens for classes and tutor products like notes and videos.
- Reactive state with Provider and RxDart, networking through Dio, push notifications via OneSignal, and crash reporting via Sentry.
04Key decisions
Built for real phones, not the demo
Shimmer skeletons for slow connections, image compression before upload, hand-rolled localisation, and Sentry in production so real crashes were visible — choices for an app used in the field across 20+ countries.
Reactive state, not manual refreshes
Provider and RxDart drive the UI from observable stores, so search, filters, and dashboards update from data changes instead of imperative screen refreshes.
05Trade-offs
- This was a front-end role: I built the Flutter and Vue clients against an API and data model owned by the backend developer, not the server itself.
- It predates the test-first discipline in my newer work — the app shipped and scaled on manual QA and production monitoring (Sentry), not an automated suite.
- The app is no longer published, so this case study links an archived 2021 snapshot rather than a live download.
06Result
A cross-platform marketplace app and web front end that real tutors and students used — 15,000+ members and 14,000+ transactions across 20+ countries, per 2021 press. It was my first production Flutter app, and the reason I care about discovery, scheduling, and payment flows feeling effortless.
07What I would improve next
- Add an automated test suite — widget and flow tests around booking and payments especially — instead of leaning on manual QA.
- Migrate the codebase to null-safety and off the now-dated Flutter 1.x packages.
- Pull the per-screen styling into a shared component and design-token system.