EMBA E-Members

An EMBA peer network is itself an asset, but that asset ends up scattered across KakaoTalk rooms, spreadsheet rosters, paper business cards, and school notice emails. "Which cohort was that person again?", "where's that notice?", "what's for lunch today?" each become a hunt through separate channels. What members need isn't flashy features but the basics - "find people, exchange cards, and don't miss the schedule or news, all in one place."

The official member community app for SKKU EMBA. Built by a small team - 1 PM and 2 developers - with James as the PM and one of the developers: defining the feature scope and priorities, and developing and maintaining the inherited Flutter codebase, shipping and updating on both the iOS and Android stores (currently v1.1.5, build 21). The focus was making the basics solid first - finding people, exchanging cards, schedule and notices - so a single member can rely on it end to end.

Current and graduated SKKU EMBA members, plus cohort organizers.

Let members handle people, cards, schedule, and news in one app instead of scattered channels, and the EMBA network becomes an asset that actually reaches you when you need it.

• As PM, defined feature scope and priorities and ran releases/updates on both the iOS and Android stores
• Took over the existing Flutter codebase and co-develop/maintain it (currently v1.1.5, build 21)
• Member directory - search and filter by cohort, job field, and name, and save a member's profile straight into the phone's contacts
• Business-card QR sharing - scanning opens the EMBA app, with a fallback to a web business card if the app isn't installed
• Mentoring - find and request a mentor, with 1:1 chat
• Schedule calendar (academic, cohort, personal), board and notices (with a built-in PDF viewer for attachments), school news and webzine (WebView), and a weekly cafeteria menu
• FCM push notifications and KO/EN localization

• Basics first - finding people, cards, schedule, and notices made solid before any flashy social features
• Cards as QR plus a web fallback - so a card still gets delivered even if the other person hasn't installed the app; no forcing an install in a networking moment
• Save contacts into the phone's native address book - an asset that stays even after leaving the app
• A single iOS/Android codebase (Flutter) - so a small team can maintain both platforms at once

A live service for SKKU EMBA members. Deployed and in use on both the iOS and Android stores (currently v1.1.5, build 21). Detailed usage metrics are private.

Confirmed the weight of taking over and running code I didn't write. Adding a new feature is easy; the real cost on inherited code is that "if I change this, what else breaks?" isn't visible. So the conclusion was that mapping the boundaries of the core flows (login, push, member search) comes before taking feature requests. The next round starts by laying regression tests on those boundaries.

• Right after the handover I started taking feature requests; I should have mapped the code's boundaries first. Stacking features on code you don't know makes regressions impossible to predict.
• It was inherited with almost no automated tests. I should have laid regression tests on the core paths earlier.