View in browser ↗
Jaegyeong Kim

Engineer who digs into problems until they become structure

Jaegyeong Kim

Frontend Engineer

Platform & DX

ReactTypeScriptNext.js

Dec 2020 – Present

Frontend Engineer / FE Team Lead (since 2021) @ Coconutsilo

About

A frontend engineer who has designed and operated 10 React-based services for KOKKOK, an O2O platform in Laos.

A frontend engineer with 6 years of experience, I've worked at Coconutsilo since December 2020, where I've built and operated admin web services from the ground up for KOKKOK, an O2O platform in Laos spanning e-commerce, ride-hailing, logistics, and taxi services. I've designed and built 10 React-based services and 3 Next.js landing pages, leading a 2–6 person frontend team along the way.

Beyond shipping features, I've designed and embedded the environment that lets the team build faster and more reliably. From separate repos to a monorepo, manual deploys to CI/CD automation, unstable API responses to runtime validation — I've led the search for and resolution of structural problems the whole team feels.

Outside of work, I'm growing my range through full-stack side projects I plan, design, build, and ship solo.

Team Lead

Since 2021, I've led frontend teams of 2–6 people, owning scheduling, technical decisions, code standardization, and onboarding.

Daily Scrum

Run at the same time every day, under 30 minutes. Focused on sharing blockers and aligning schedules

New Hire Onboarding

Documented everything from local environment setup to code conventions, architecture, and deploy process — thorough enough for new hires to onboard on their own, cutting communication overhead

Technical Decision-Making

Led timing and direction decisions for TypeScript adoption, monorepo migration, Vite migration, and more

Development Standards

Established type naming rules, component patterns, and a pre-PR checklist

Key Achievements

Platform and architecture improvements I led to boost team productivity and service stability

Type-safe API Layer

Read article (KR) →

Problem

When the API spec drifted, the service went down, and pinpointing the offending field took a long time. Components that missed undefined handling also caused repeated screen-breaking incidents.

Solution

  1. 01Typia runtime validation — on every API response, mismatched fields are logged immediately and treated as undefined so the service keeps running
  2. 02Generalized via a factory function — pass a type, and every one of the 10 apps gets the same validation automatically
  3. 03RecursiveUndefined (alias: Pessimistic) type design — every API response field is assumed possibly undefined, forcing components to handle undefined at the type level
  4. 04Typia's compile-time transform ran on every local dev server start, slowing startup — added a needTypia helper that decides whether to apply the plugin from the script name, splitting dev from dev-typia so validation stays off by default, is enabled only when checking for spec drift, and always stays on for builds

Result

  • Service keeps running normally even when the API spec drifts
  • The offending field can be pinpointed the moment a mismatch occurs
  • Splitting the validation mode cut dev server startup by up to 88% (service A: 53.8s → 6.3s, measured to FCP)

Monorepo Architecture

Read article (KR) →

Problem

As services grew, shared components and utilities kept getting copy-pasted across repos. Fixing a bug in one place didn't propagate to the others, causing repeated version drift.

Solution

  1. 01Migrated 10 scattered multi-repos into a single Turborepo-based monorepo
  2. 02Structured shared code into 7 category packages — apis · components · hooks · utils · services · types · styles — with 164 components, 46 hooks, and 40 utils
  3. 03Built 2,245 tests across hooks, utils, and components with Vitest + Testing Library, catching regressions before they ship

Result

  • 10 apps share identical packages — fixes apply instantly everywhere
  • 2,245 tests across hooks/utils/components modules — run automatically before every push to catch regressions in shared code early

CI/CD Automation

Read article (KR) →

Problem

Even though 10 apps lived in one monorepo, every deploy meant a person manually repeating the same steps — a local build, S3 upload, and CloudFront invalidation for React. The procedure lived in people's heads instead of being automated, so it had to be re-explained every time ownership changed, and all that manual work meant human error kept creeping in. Rollbacks were manual recoveries that took a long time too.

Solution

  1. 01React (SPA) — split build/upload from deploy across 2 GitHub Actions workflows, so an already-built version can redeploy or roll back instantly without rebuilding
  2. 02A shared validation workflow automatically checks version format, per-environment permissions, and that the target AWS resources exist before every deploy
  3. 03Even inside the monorepo, services deploy independently rather than all at once — any service can ship on its own schedule
  4. 04Semantic versioning keeps every build in S3, enabling instant rollback

Result

  • Anyone can run the same deploy procedure without hand-offs, no matter who owns the service now
  • No deployment expertise needed — anyone can ship with a single command
  • The validation workflow auto-checks version format and permissions, blocking bad deploys before they happen
  • Deploy and rollback both complete in minutes
  • Eliminated repetitive manual work, preventing human error

Bundle Optimization

Problem

The React apps' build output was concentrated into a single index.js, making initial load slow.

Solution

  1. 01Code-split with lazy imports, scoping the initial load to a per-page basis
  2. 02Designed Vite manualChunks separation rules — vendor libraries, shared packages, and app code split by kind, so unchanged libraries reuse the browser cache
  3. 03Removed 1,600 barrel files and moved assets/i18n into each app — blocking unused SVGs, images, and language files from being bundled

Result

  • Entry bundle cut up to 92% (carAdmin 4,990kB → 375kB)
  • index.js cut up to 91% after manualChunks (carInspection 925kB → 86kB)

Global State Optimization

Problem

Global state was managed through ContextAPI, and components subscribed to a wider slice of state than they actually needed. So a single state change re-rendered unrelated child components too, and some of that turned into real bugs. Because useModal subscribed to the entire modals array, logging out triggered modal state reset → full re-render → API re-request with an expired token → 401 error → a blank white screen. We also confirmed via React DevTools Profiler that, since RoutePathProvider, AuthProvider, and others were ContextAPI-based, every click on the NavigationBar re-rendered every icon, button, and dropdown inside the Header.

Solution

  1. 01Converted ContextAPI-based global state to Zustand + selectors, narrowing subscriptions so components only re-render when the value they actually use changes
  2. 02Fixed a logout bug by narrowing useModal's subscription to only the function references it needed, removing the full modals-array subscription
  3. 03Converted RoutePathProvider, AuthProvider (class instance + ContextAPI), useGoogleMap, Toast, Navbar, and others to Zustand selectors and React.memo
  4. 04Replaced the useLocation dependency with window.location.pathname and a router singleton pattern, removing extra re-renders from react-router-dom state changes
  5. 05Moved the improved shared code (Auth.tsx, authStore.ts, etc.) into packages/ and rolled it out across all 10 apps at once

Result

  • Fixed the 401 error + white screen bug on logout
  • Eliminated full Header re-renders on NavigationBar clicks (confirmed via React DevTools Profiler)
  • Overhauled the unnecessary re-render structure across all 10 apps

Other

Other improvements

MSW-based Dev Environment

Introduced MSW so screen development wouldn't be blocked while the API server was still in progress. Led MSW and Typia setup for a new event app (kokkok-event) and built mocks for its 3 event features — friend invites, attendance check-in, and a roulette wheel — and batch-updated affected mocks whenever server enums changed. Mock handlers now cover 70 files across 5 apps, with MSW templated by default in the app-scaffolding script.

Faster VSCode autocomplete (10s → 2s)

As the i18next translation type declarations grew in the monorepo, autocomplete computation took up to 10 seconds. Upgraded to TypeScript 5, split JSON per service, simplified type declarations (typeof json → Record<key, string>), and removed roughly 1,600 barrel files in stages, cutting it to 2 seconds (-80%).

Duplicate API call prevention (useSafeMutation)

Built a useMutation-based custom hook to stop the same API firing multiple times on rapid button clicks. Assigns a unique ID to in-flight requests to block duplicates, and forces every hook usage to explicitly choose an error-handling mode (global or per-screen), preventing missed error handling across the team.

Commit automation (Husky + lint-staged)

Enforces ESLint auto-fix and Prettier formatting before every commit, blocks commits without an allowed prefix, and analyzes staged files to auto-prepend the service name to the commit message. Removed code-style nitpicks from PR review, freeing reviewers to focus on core logic.

Static analysis automation (ESLint / Stylelint)

ESLint — auto-sorts import order and enforces import type. Stylelint — auto-sorts CSS property order. Automated static analysis keeps reviews focused on core logic instead of style nitpicks.

Migrations

Summary of technology migrations

FromToBackgroundResult
JavaScriptTypeScriptRuntime errors only surfaced after deployCompile-time error detection, improved DX
Redux + Redux-SagaTanStack QueryExcessive server-state boilerplateSignificantly less server-state boilerplate
CRAViteSlow build and HMRBuild time cut drastically, instant HMR
Ad-hoc per formReact Hook Form + ZodDuplicated logic across each formStandardized form logic, more reuse
YupZodPoor TypeScript fit, complex codeAuto-inferred types from schema, improved DX
NoneMSWBE delays pushed back FE schedules tooFE and BE development schedules fully decoupled
npmpnpmDuplicate node_modules slowed disk and installsNoticeably faster installs, lower disk usage
Separate reposMonorepo (Turborepo)Duplicated shared code, version mismatches10 apps share identical packages, fixes apply instantly everywhere

Work

KOKKOK Platform

An O2O platform in Laos. Designed, built, and operate 10 React-based services and 3 Next.js landing pages.

KOKKOK Admin WEB

B2B InternalService Intro

Initial architecture design, shared component design, API integration, permission system design, ongoing operations

The main admin managing the entire KOKKOK platform — food delivery, mart delivery, e-commerce, eGift, driver/customer management, and support. Integrates 4 business domains, combining domain-level access control, i18n, real-time map integration, and large-scale data tables.

172

Pages

4

Domains

2–6

Team Size

ReactTypeScriptTanStack QueryZustandEmotionGoogle Maps APIi18nextTypiaMSWViteTurborepo

KOKKOK Move Admin WEB

B2B InternalService Intro Android iOS

Initial project setup, core screen development, API integration, map-based vehicle tracking, ongoing operations and maintenance

Admin for an electric tuk-tuk taxi service in Laos. Real-time vehicle tracking, driver/vehicle/battery/customer management, dispatch monitoring, rankings, and more — combining a GPS-based live map with IoT device status.

27

Pages

Live GPS

Feature

ReactTypeScriptTanStack QueryZustandEmotionGoogle Maps APIi18nextTypiaMSWViteTurborepo

KOKKOK Car Admin WEB

B2B InternalService Intro Android iOS

Initial project setup, vehicle listing/management screens, API integration, applying shared components, ongoing operations and maintenance

Admin for a new/used car sales platform in Laos. Vehicle listing/sales management, ad banners, dealer/customer management, and more.

55

Pages

Vehicle listing & sales

Features

ReactTypeScriptTanStack QueryZustandEmotioni18nextTypiaMSWViteTurborepo

Other Admin Tools

KOKKOK Logistics Admin

Logistics delivery/dispatch/invoice management, driver/vehicle registration (16 pages)

KOKKOK Delivery

Delivery order management (9 pages)

KOKKOK Car Inspection

Vehicle inspection admin

KOKKOK Move IoT

IoT device management admin

KOKKOK Event

Event pages — check-ins, roulette, and more

KOKKOK Store

Store management admin

KOKKOK Move Ranking

Driver-facing ranking view — rank and average trip metrics (1 page)

3 Landing Pages

KOKKOK service intro, Coconutsilo company intro, data voucher application. Responsive web/mobile UI, multilingual.

Next.jsTypeScriptEmotioni18nextTanStack Query

Side

Side projects

Asset Management Studio

Live

May 2026 · Solo (planning, design, development, and deployment end-to-end)

A personal asset tracking web app unifying 12 asset types — stocks, ETFs, deposits, real estate, crypto, and more. Records principal/valuation by date, auto-calculates returns and IRR, integrates live quotes from Yahoo Finance/Finnhub, visualizes portfolios with Recharts, offers a no-signup demo mode, dark mode, and Korean/English support.

12

Asset Types

Playwright

E2E Tests

Vercel

Deploy

New tech adopted

  • Next.js App Router + React 19
  • Full-stack design on Supabase
  • Server-side rate limiting for external quote APIs (prevents excessive requests)
  • Built a Vitest + Playwright E2E test environment
Next.jsReact 19TypeScriptSupabaseZustandReact Hook FormZodRechartsVitestPlaywright

Moyu Miyu

Jun 2026 · Solo

A Flutter-based mobile app that helps track and manage exclusive breastfeeding. In progress, with a Supabase-based backend integration.

Mobile

Platform

In progress

Status

FlutterDartSupabase

Bulletin Viewer PWA (Jamsil Joongang Church)

Live

Jun 2026 · Solo (planning, design, development, and deployment end-to-end)

A responsive PWA usable across mobile, tablet, and web, running in production for real users. Minimizes image network requests with 3-layer caching — R2 Cache-Control, next/image optimization, and cache-tag-based revalidation. Admin panel covers bulletin upload with drag-and-drop reordering, admin account management, login history, and R2 free-tier usage monitoring. Also crawls existing bulletin images from the church's official website with preview-then-import bulk registration. A native Flutter app is planned for future release.

Responsive PWA

Platform

Vitest + Playwright

Tests

Vercel

Deploy

Flutter app planned

Roadmap

Next.js 16React 19TypeScriptTailwind CSS v4Drizzle ORMSupabaseCloudflare R2Playwright