EMBA E-Members

Project handover & access transfer

I took on the messiest, most important work at the start: turning someone else's code and scattered ops access into a state I could actually control.

• -Audited the entire existing codebase I hadn't written and listed the fixes/refactors (accepting the handicap that inherited code takes longer)
• -Stood up and migrated three new GitHub repos - app, admin, backend
• -Cleaned up AWS access - identified and escalated RDS / IP-whitelist issues
• -Secured Google Play Console admin rights and confirmed the vendor's access was revoked
• -Invited an Apple Developer team admin, revoked and reissued the signing key (.p8), removed the vendor's member, and checked the distribution certificates
• -Volunteered to take on the backend too where things stalled, to cover the scope gap

Skills · Schedule · Prioritization · Risk · Resourcing

Scoping & requirements alignment

• -Fixed scattered discussions into meeting notes and an agreed scope
• -Made "hand it over spec-complete" the principle for the handover, which surfaced key spec gaps to re-align on
• -Parked the cafeteria-menu feature while its decision lagged, and finished the search/filter, webzine, and business-card UI first to stop the delay from spreading

Skills · Scoping · Scope alignment

Schedule & bottleneck management

• -Built and ran a schedule worked backward from the deadline
• -Split the backend bottleneck into discrete tasks and reported progress transparently
• -Answered stakeholders' schedule questions item by item, and reframed vague questions into answerable ones before answering

Skills · Schedule · Bottleneck management

Visibility & stakeholder communication

I was the translator and single reporting channel between the dev team and the non-technical student council.

• -Ran a status board - done / in progress / not started, frontend and backend split out, existing vs. added requirements distinguished
• -Shared a daily progress report with the whole council, written in language a non-developer could follow
• -Surfaced risks and constraints rather than hiding them, always paired with a set of realistic options (re-outsource / adjust scope / re-prioritize)
• -Under pressure, took responsibility first and pivoted to prevention

Skills · Stakeholder management · Reporting · Expectation setting

Quality & security

I applied fourteen years of QA even outside the requested scope.

• -Proactively found and fixed 6+ security issues outside the request (plaintext passwords, sensitive data in logs, exposed keys, etc.)
• -Built a test environment for non-developers - Firebase App Distribution, tester registration, demo videos
• -Wrote the QA reports and test guides myself

Skills · Quality · Security · Test environment

Release

I carried the simultaneous iOS/Android launch across the line, just before the term ended.

• -Set up and deployed a dedicated business-card domain with deep links and app auto-open - so even non-members without the app could view a card
• -Knowing the "avoid Friday/weekend releases" rule, still decided on a Friday release - conditioned on monitoring - to ship within the term
• -Result: on 2026-06-25 both the Android and iOS reviews were approved and shipped the same day

Skills · Release · App-store ops · Infra decisions

Operations handover & sustainability

I closed this out not by "ending" it but by making it something the next owners could pick up.

• -Cafeteria menu - documented the missing-data and undecided-owner issues, and proposed a phased plan (frontend done now, backend over the break)
• -Took direct ownership of the handover discussion with the next (66th) student council and its president
• -Surfaced ops-efficiency ideas like auto-checking club-fee payment status
• -Handled many usability improvements - auto-saving contacts, card layout, consistent labeling for members with no employer

Skills · Operations transition · Handover · Product improvement

Thinks in interfaces

I treated the FE/BE boundary as a contract - settling what gets exchanged and the dependencies first, before starting the work.

Fluent with collaboration tools and protocol

I specified the APIs I needed down to endpoints and field lists, and when a subdomain issue blocked us I built a small express server myself and pushed it to the repo to unblock proactively. I attached screenshots as evidence.

Closes ambiguity with evidence

For a vague issue - "a certain cohort doesn't appear in the search dropdown" - I went hypothesis -> hands-on test -> reading the actual code (the cohort field is nullable, so it had been registered as "not selected"), and concluded "no fix needed, leave as is." I also split what to do now from what to improve later (make it required, CSV bulk import, etc.).

Holds the quality and release gate

When the backend announced a production deploy, I asked for a QA / integration check gate before shipping, stopping a deploy with no verification. The most striking part of the collaboration.

Creates psychological safety

I admitted my own mistakes first ("I think I missed that") and didn't push the fix burden onto the other person ("it's structurally fine, better that I handle it"). As a result, they too could name their own mistakes without getting defensive.

Polishing the text tone behind a fast urge to confirm

When I spot an issue, I have a strong urge to confirm and pin it down quickly. In person that reads as drive, but in text the same intent can come across drier, so taking one more pass on tone makes collaboration smoother.

Try Adding one line - "I think I lost the context here; could you walk me through it once?" - gets the same information across more gently.