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. The first round (handover on 30 April to launch on 25 June) was a small team of 1 PM and 2 developers, with James as PM and one of the developers: defining scope and priorities, developing and maintaining the inherited Flutter codebase, and carrying it to a simultaneous iOS and Android launch. The second round (26 June to October) was different. The vendor's backend developers made their last commit on 14 June, so every commit and all 225 PRs across five repos since then - app, backend (NestJS and MySQL), admin (Next.js), card web (Express), and the election system - were one person's work. The app version on main is 2.0.0+39 (2026-08-27). Whether 2.0.0 actually reached the stores is not recorded in the repos, and a note from 18 September says production was still not forcing old versions to update. Only what is verified is written here. The basics a single member relies on end to end - finding people, exchanging cards, schedule and notices - came first, then it widened into what the student council actually needed to run: meal distribution, bookings, and elections.

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 develop and maintain it (2.0.0+39 on main as of 2026-08-27, after the 25 June launch)
• 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
• The 2.0 round (July to September) - two business cards (the school card drawn by the app, the company card as an uploaded image), a 3-minute token and screenshot blocking on the my-page QR, welfare and partner benefits plus transit guidance tabs, bookings at council-subsidised venues, automatic school notice sync (attachments copied to our own server), a live shuttle modal
• Meal distribution kiosk - QR token validation on a tablet kiosk (/kiosk) and a staff phone (/operator), per-session and per-weekday rosters with reserves, remaining stock shown in the app, weekday auto-open at 16:00 and close at 23:00 (Saturday 10:00 and 18:00), and holiday gift pickup in a separate table
• The backend (NestJS, TypeORM, MySQL), admin (Next.js), and card web (Express) too - admin levels 300/255/233/222 with a scope decorator, lazy bcrypt upgrade on login, academic calendar and admission guide PDF management, real paging on the board
• Embedded the degree planner as a web view - remote bundle first, bundled app asset as fallback. Its data moved from Supabase to the EMBA backend
• Built a central election system for the cohort 120 leader election in a day and mounted it on the card web (17 September), then ran three rounds of a slogan vote on the same structure
• Started the App Transfer of the Apple and Google Play accounts held by the vendor on 4 September and closed it on the 17th - new privacy policy and support pages on the card web
• The 66th council rebrand (2.0.0) - colours, slogan, and board ID pulled into a CouncilBrand layer so the next council can change them again

• 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
• QR as a 3-minute token with screenshot blocking - the card QR doubles as the meal check-in, so a reused screenshot has to fail. The kiosk validates the token once the grace period ended
• Proxy pickup was built and reverted the same day (20 August) - once it was clear it broke one-person-one-meal uniqueness, holiday gifts went into a separate table so they never mix with meal uniqueness
• School notice attachments are copied to our own server - the app cannot open external links, so that constraint was absorbed into the sync design. The welfare source watcher cron only compares hashes; writes need a human
• Email is left out of the unauthenticated card API - a card must be delivered, but it must not become a harvestable contact
• A flowing "SKKU EMBA" mark only on the partner detail screen - the purpose is forgery prevention, so its scope was narrowed twice

• The boundaries of inherited code (token expiry/re-login, network failures, empty states, missed push) hold up in real members' hands, not just a demo
• Business-card QR - when the other person hasn't installed the app, the mobile-browser web fallback still delivers the card
• The single Flutter codebase behaves identically on iOS and Android (including deep links and push)
• The proactively-found security issues (plaintext passwords, sensitive data in logs, exposed keys) are verified as actually closed
• Inherited with no regression tests on the core flows (login, push, member search) - where is "same input, same result" guaranteed?
• Are stage and production really separated - on 20 August the production API pointed at the stage DB for about 20 minutes (sourcing .env then pm2 --update-env). Subshell sourcing, no --update-env, and a post-deploy DB sanity curl went into the procedure
• Is an outage being misread as a deploy regression - on 16 September an AWS non-payment suspension stopped Route 53, EC2, and RDS together, and it was first read as a deploy problem. No data was lost; the missing billing alert is the open item
• The force-update threshold and the kiosk grace period are out of step - production /version/check still lets old versions through while the kiosk refuses a QR without a token. The path where an old-app user is turned away at the meal line is known and not yet closed
• Unauthenticated card lookups use sequential IDs, so they can be enumerated - mem_privacy is a consent flag, not a publish flag. Recorded as unresolved
• 1,940 of 1,979 member passwords were plaintext (18 August) - a lazy bcrypt upgrade on login was added
• Did regression tests actually grow - 24 member-directory model tests were restored from an old branch (PR #67); backend 34 spec files, card web 61 tests, election 159. Admin has 0 and there is no CI/CD

A live service for SKKU EMBA members. Launched on both the iOS and Android stores on 2026-06-25, 2.0.0+39 on main (2026-08-27). 1,975 members shown in the app (24 August). 225 PRs across five repos since 26 June (app 59, backend 64, admin 28, card web 72, election 2). Weekday meal rosters of 92 (Tue), 82 (Wed), 65 (Thu), and 118 (Sat). 16 school notices auto-registered, 0 blocked. Cohort 120 leader election turnout 94.6% (35 of 37). Download counts, store reviews, and cumulative meal check-ins are not recorded.

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. The second round's result splits in two. The product widened: cards, welfare, bookings, the kiosk, notice sync, the degree planner, and elections landed within three months, and the store accounts came over from the vendor. The promise to lay regression tests was only half kept: model tests were restored and tests were added to the backend, card web, and election, but there is still no CI and admin has none. In between there were two incidents, 20 minutes pointed at the stage DB and a day of AWS suspension. Neither lost data, and both became written procedure.

• 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.
• Once it became a one-person team, "no approval needed" slid easily toward "no verification". The rule that a production deploy is a separate decision after stage verification exists because of that, and the 20 August incident taught that the rule applies to a single environment variable line too.
• Secret keys were echoed to the terminal twice (15 August, 16 September). Both were rotated, but the rule of never typing credentials on screen and moving them as files was written only after the second time.