A closer
look.
Customer screens,
operational workflows,
and the frontend between.
Development and
technical decisions.
Since March 2022, I have built customer websites, WebViews, and operations tools at The SWING. Across SWING, SWAP, and Yellow Bus, my work has included early service builds, feature development, technical reviews, and service transitions.
Since September 2025, I have served as SWAP FE Part Lead, working on technical decisions, major features, and code reviews. Alongside hands-on development, I align API changes, shared structures, and release decisions with colleagues.
Much of my work involves learning the order in which operators do their jobs, aligning data contracts with backend colleagues, and checking how screens connect with app and CX colleagues.
My work across products
SWING · SWAP · YELLOW BUS
Customer-facing screens
I build flows for finding and ordering products and for continuing login and payment inside an app.
- SWING customer WebViews
- SWAP product discovery and first orders
- Business portal
Operations tools
I work on screens where task order and permissions matter, such as contracts, dispatch, and settlement.
- Bike operations Admin
- Yellow Bus operations
- SWING partner settlement
Engineering and integration
I look at old and new systems working together, app bridges, screen performance, and verification practices.
- SWAP Admin V2
- SWING website performance
- WebView QA Shell
Technical choices
These examples show how I used each tool to solve a problem.
React · TypeScript
I built customer-facing and operations Admin screens, aligning response types, user types, form inputs, and error states. I kept fixtures used before an API was defined separate, then integrated the real responses.
Data flow in the bike screens ↗TanStack Query · SWR
I handled when a lookup could run, which conditions distinguished its data, and what to refetch after edits alongside each screen’s workflow.
Trip lookups and refresh ↗Next.js · Web performance
I separated server and client boundaries and prerendered pages. I changed when images were generated, when iframes loaded, and how fonts were requested, then compared results with local Lighthouse runs.
Initial load path and build processing ↗WebView · QA
I connected native bridges with web screens and handled return flows after payment. I paired Playwright automation with direct screen checks and built a public WebView QA shell.
WebView and public QA tool ↗How I work
These examples show the choices I made and how I checked them.
Workflow first
I check why a screen is needed and what the user does next, then identify API fields and exceptional states.
For the Yellow Bus student list, I discussed how the new response contract should handle missing or multiple guardians.
Migration paths
When adding a new screen, I check whether old data and navigation paths remain and plan how to connect them.
In SWAP Admin V2, I contributed to screen and API changes while old and new task data coexisted.
Screen checks beyond automation
Even after automation passes, I inspect empty states and differences in real responses on screen.
On Bike screens, I found a response object missing for one user type, then repeated E2E and manual checks after the fix.
Trade-offs and measurement
I consider rendering and transferred assets together, then measure before and after under the same conditions.
On the SWING website, I adjusted video, images, fonts, and rendering paths, then compared medians from local Lighthouse mobile simulations.
Experience
My frontend career began in March 2022.
SWAP FE Part Lead
Technical decisions, major feature development, and code reviews within SWAP FE.
Yellow Bus squad
Rebuilt operations features for an acquired service and contributed to initial stabilization.
The SWING · Frontend Engineer
Built customer websites, WebViews, and operations tools for SWING, SWAP, and Yellow Bus.
Minestrone · student venture
Developed VR controllers, party games, and an MVP for a Chinese university student resale platform. Separate from my professional frontend experience.
Gwangju Software Meister High School
Software Development
Information Processing Craftsman
2023.09
Tools I build and share
Personal projects spanning reusable interfaces, browser QA and error logging.
Hyeonse Design System
A reusable design system extracted from this portfolio, bringing its visual language and display settings to other personal projects.
- Packaged semantic CSS tokens for color, type and spacing with React controls for theme, accent, density, corners and motion.
- Used in this portfolio and Flow QA. Includes a CSS token audit CLI and a reusable agent skill for building, migrating and reviewing interfaces.
- TypeScript
- React
- CSS tokens
Flow QA
A local QA tool that turns user flows into reviewable test cases and browser execution results into reports linked to evidence.
- Built the flow and case schemas, model integration, compilation of allowed steps, CLI and English/Korean UI. Browser execution uses tester-army/e2e.
- Tracks source changes with flow hashes and blocks ambiguous expectations. Separates assertion failures from environment blockers, linking attempts and collected evidence in each run’s report.
- TypeScript
- Node.js
- e2e
- Zod
Browser Error Log
A self-hostable toolkit for collecting, storing and inspecting browser errors, with an SDK, collector and viewer.
- Published a framework-independent SDK, React Error Boundary adapter and shared event contract on npm. Captures global errors, unhandled rejections and network failures.
- Bounded queues, batches and retries feed a Node.js collector with SQLite or JSONL storage. The viewer provides filters, stack and request details, and JSON import/export.
- TypeScript
- React
- Node.js
- SQLite
More tools and contributions
Other tools I published and contributions to open source.
Explore four projects
in more detail.