Duke Jeon

01 Driver and guardian shuttle apps

New

• Co-planned the driver and guardian apps, then built and shipped them alone Co-planned the service with one backend developer. Solely owned design, development, live-run QA, and Android and iOS store release for both apps.
• Chose the architecture and state management for consistent rules and tests Chose Clean Architecture so the rules stayed consistent, tests stayed practical, and the app did not depend on one library.
  Used a widely known structure as the way to read the code, and treated AI as a way to cut the cost of repeated boilerplate.
  Chose Riverpod after comparing how easy tests were to write, the learning cost, and how actively each option was maintained at the time.
  Also weighed the rules GetX needs for its convenient global access, and the extra code an event-based BLoC would add.
  Split auth, notices, runs, permissions, and profile by feature, and put services shared by both apps into core.
• Automatic boarding that cuts input while driving Added automatic handling so drivers, including older users, would not have to mark each passenger as boarded, alighted, or absent while driving. Inside a stop geofence, a GPS speed of 0 counts as a stop, the boarding record is written automatically, and it is sent when the bus leaves the zone. A crowded run can send at the next stop, and a confirmed record can be edited for a late passenger.
• Location handling changed to follow the actual trip Snapping coordinates to the route could not show the real trip where the two directions overlap or the bus left the route, so I switched to filtering and correcting measured locations. I dropped low-accuracy or stale points, filtered outliers with distance, time, speed, direction, and the following point, then applied a Kalman filter. Live drives and walks were used to compare the real trip with the position on screen.

• Flutter
• Dart
• Clean Architecture
• Riverpod
• Firebase

• Wonder Shuttle for School (Guardian)
• Wonder Shuttle for School (Driver)

02 Existing Android and iOS apps

Legacy

• Maintained 16 existing Android and iOS apps Separately from the driver and guardian Flutter apps, maintained 16 existing Java (Android) and Swift (iOS) apps.
• Seonggong Bus Android average daily crashes, 200.2 to 3.3 Play Console logs showed causes such as reading a list index past its length.
  I used AI to inspect the legacy code and added bounds checks before index access, among other fixes.
  Average daily crashes fell from 200.2 over the 28 days before the fix to 3.3 across the following four months.
  User volume and how the counts were collected did not change much over that comparison, and the remaining crashes were only on versions from before the forced update.
• Merged 8 white-label projects into 2 Seonggong Bus, Naepyeon Jung-gu Bus, Nowon Haengbok Bus, and Gwanak Ganggamchan Bus were separate projects, and their shared code had drifted.
  I merged the 8 Android and iOS projects into one project per platform, 2 in total, and kept service differences in Android Build Variants and iOS Targets.
  A shared change is now made once per platform and reaches all 4 services.
  Each service was checked with a manual test.

• Java
• Swift
• Android
• iOS

03 Takgu Power Plant 24

• Moved reservation lookup to WebSocket, and restored state on reconnect With a backend developer, replaced 10-second polling with WebSocket.
  While disconnected, the last reservation stays on screen.
  On reconnect, the latest data removes a canceled reservation and replaces one whose ID changed.
  Remaining time is calculated from the reservation start time, so the timer continues.
• Traced missing reservations by keeping logs and comparing records Stored the layer and method of each error locally, and deleted a log only after the server had received it. Comparing those logs with network and MDM records showed aging network equipment was the cause. After the equipment was replaced, the same symptom did not recur.
• Remote management of about 80 devices across 20 stores Used Headwind MDM to reboot devices and check logs without a site visit. The app launches after reboot, so about 80 devices across 20 stores are managed remotely.

• Flutter
• Dart
• BLoC
• WebSocket
• Firebase

04 Modustream

• Forked fl_chart so the glucose and insulin charts stay in sync To pan and zoom the insulin bar chart and the glucose line chart together, I changed gesture, coordinate, and rendering handling inside cs_chart, a fork of fl_chart. InteractiveViewer ties the two charts to one gesture, and the tooltip follows the coordinates when the chart is flipped.
• Rendering tuned to zoom level and what is on screen Pan and zoom stuttered on 24 hours of data, so points are aggregated into 5-minute, 30-minute, 1-hour, or 3-hour buckets by zoom level. Off-screen data is not drawn. Checking by hand, the stutter dropped and the gesture felt better.
• Clearer pump BLE code Wrote down what the BLE codes for battery, delivery, and volume mean, and noted what each method handles so the code is easier to read.
• Less duplicated onboarding UI, from code review Suggested pulling the AppBar and spacing repeated on each step into a shared layout. The developer who owned the screen applied that structure.

Chart example

• Flutter
• Dart
• BLoC
• BLE
• Firebase

05 Tango & Go

• Scan history kept separate from server processing state On an unstable warehouse network, scan history is saved locally right away, and processing state is updated only after the server responds. If there is no response, a later lookup or retry updates the state. Reopening the app also loads the server data.
• Invoices sent in batches after external-server timeouts Sending 200 invoices at once timed out, so they go out in batches of 20 and only the failed ones are retried. Together with server-side improvements, 200 to 300 invoices finish in about 5 seconds.
• Delivery map from administrative-boundary data Added a delivery-status map to the existing city, district, and neighborhood screen, using boundaries simplified in QGIS. The chosen table or map view is kept in SharedPreferences.
• Location tracking control while a navigation app is open Used flutter_overlay_window so tracking can be turned on or off while another app is in front. Location comes from FusedLocationProviderClient, and completing a delivery continues into the photo upload.
• Smaller delivery-completion photos Lowered the resolution of 4–5MB photos before upload, while keeping the unit number readable.

• Flutter
• Dart
• GetX

• Tango & Go

06 Pickaround

Around · solo · 2025.12

• Built a web MVP for sashimi recommendations and species info, and connected ordering, payment, and webhooks

• bubble.io
• TossPayments
• Amplitude

07 Jisponge

Side project · PM, design, and development, solo

• Planned, designed, built, and deployed a Flutter web site for a sponge and sporting-goods company

• Flutter
• Dart
• Supabase
• Firebase