Product-minded Full-stack Developer
Kihwan Lee
Product-minded full-stack developer building reservation, payment, CRM, and on-site POS systems as one coherent product.
Busan-based full-stack developer with over 10 years of experience building responsive, user-friendly web products with modern technologies like React, Node.js, Django, and cloud platforms. Interests span web development, game development, artificial intelligence, and robotics, with a strength in rapid prototyping that turns ideas into concrete proof of concept quickly.
Product Summary
Connecting customer, operator, and field workflows through one product state
The core is not the number of screens. It is a structure where different product surfaces consistently share the same order, reservation, payment, permission, and site-scoped business state.
Customers can browse products, pay, reserve, and review purchase history in one connected flow.
Operators can handle reservations, orders, payment errors, statistics, and site-scoped permissions quickly.
On-site payments, order state, terminal settings, and recovery flows are designed for tablet and web operation.
Operational risk is managed through GCP, Cloud SQL, Storage, deployment scripts, and durable work records.
Built Projects
Prototypes and services I built
Web services built to quickly validate product hypotheses or demonstrate real user flows.
Moyo Travel
A travel agency prototype for validating luxury travel landing, tour discovery, and inquiry flows. The interface centers on large visuals and package-style travel information structure.
View site
tikat
A Korean learning platform centered on a two-week challenge and free demo entry. It includes learning conversion CTAs, language selection, and login flow.
View site
Aling
A branding and download landing page for a small-business and influencer matching platform. It highlights app positioning, store CTAs, and mobile screen previews.
View siteProduct Screens
Product scope through real service screens
Customer reservation, CRM operations, and field POS screens are connected within the same product flow. Screenshots are based on staging screens, with sensitive account and reservation information masked.
CRM operations board: dashboard and store settings
Operators can review operating status and manage branch landing/store information in the same back office.
CRM reservation board: products, calendar, reservation list
Reservation products, daily status, and reservation handling lists are connected as one operating flow.
Customer web: reservation detail
Date, seat, details, and reservation CTA are connected in one conversion-oriented screen.
Customer web: my page
A self-service screen where customers can review reservation, ticket, order, and coupon status.
POS: cashier sales screen
Table/pickup selection, menu selection, cart, and terminal payment request are connected in one flow.
POS: table management
Field tables and order context are managed so online reservations and on-site sales share the same operating model.
Product Capabilities
Core product capabilities
Feature boundaries and data contracts are aligned so customers, operators, and field staff can work from the same service state.
Reservation/order/payment state flow
The backend contract keeps customer web, CRM, and POS aligned around the same order state.
- Tech base
- Django/DRF API, state transition rules, payment-provider response normalization
- Product effect
- Payment success, failure, and exception handling connect to customer flow and operational response
CRM operations workflow
Dense screens support repeated operator work such as reservation changes, payment errors, and statistics checks.
- Tech base
- React, Vite, server pagination, bulk actions, CSV export
- Product effect
- Task-oriented operations UI that reduces repeated handling cost
Site-scoped permission model
Operational permissions are interpreted by site role and action-level policy, not only global admin status.
- Tech base
- Django permission gate, site-scoped permission helper, targeted tests
- Product effect
- A permission contract that balances security and operational convenience
On-site POS sales flow
Field staff need fast product selection, pending-payment locks, and recoverable order state.
- Tech base
- Expo Router, React Native, React Query, local device context
- Product effect
- Field touch flow and payment stability stay inside the same UX
Customer my page and purchase history
Customers need accurate site-scoped purchase history, reservation information, coupon, and ticket status.
- Tech base
- React customer web, summary endpoint, shared modal contract
- Product effect
- Front-end screens and backend aggregation rules stay aligned
Operating cost and media management
Operating cost is not outside the product. It is part of keeping service quality sustainable.
- Tech base
- GCP Storage/CDN checks, signed URL separation, dry-run based processing scripts
- Product effect
- Operational standards that consider cost, security, and visibility together
Architecture
Service architecture
The center is the Django API contract. Each client has a different purpose, but they share the same data state and operating rules.
Customer, operator, and cashier experiences are separated at the UI layer but converge on the same backend contract and operational evidence.
Case Studies
Representative project deep dives
These cases show product-minded development from problem definition to contract design, verification, and operational rollout.
Reservation operations flow
CRM, reservation product, calendar
When customer-facing reservation products and operator reservation lists/calendars drift, field operations become unstable.
Product exposure, seat/date inventory, reservation status, cancellation, and entry handling happen across different screens.
Reservation products, calendar, and reservation lists are connected through the same Django API contract and site scope.
A CRM structure where product management, daily operations, and individual reservation handling stay in one flow.
Connecting store settings to customer screens
Site settings, customer web, product detail
Store information edited by operators must be reflected consistently in customer landing and reservation detail screens.
Brand information, product description, dates, seats, and CTA can appear separated between operator and customer surfaces.
Site settings, product detail, seat selection, and my-page summary are connected through the same site-aware data flow.
A product structure where CRM setting changes carry through to customer experience.
Standalone POS field workflow
Expo POS, cashier workflow
Field sales need fast selection, payment locks, and recovery after failure more than screen switching.
Terminal settings, site selection, order state, and pending-payment state must not drift during use.
Login-time site context, device-local settings, and cart/payment state machine are separated.
Field operation flow becomes simpler on tablet and web, with better state recovery potential.
Technical Stack
Technical stack and selection criteria
The stack is selected around product flow, operational stability, and verifiability.
Backend / API
- Django 5, Django REST Framework, Simple JWT
- PostgreSQL/PostGIS, Redis, Celery
- API documentation with drf-spectacular and drf-yasg
- Payment helper, permission gate, site-scoped business rules
Frontend / CRM / Web
- React 19, TypeScript, Vite, pnpm
- TanStack Query, Zustand, React Router
- Radix UI, Headless UI, Tailwind CSS, Bootstrap migration surface
- Server pagination, modal contract, toast/dialog UX, export flows
Mobile / POS
- Expo 55, React Native 0.83, Expo Router
- React Query, Secure Store, SVG/QR flows
- Device-local settings, terminal identity, payment state locks
- Android/Web shared cashier interaction model
Infra / Verification
- GCP, Cloud SQL, Cloud Storage, deployment scripts
- Targeted Django tests, Vitest, TypeScript checks
- Billing export and resource state validation
- Progress docs and task snapshots for operational continuity
UI / UX
UX principles by user type
Customers, operators, and field staff use the same product, but their speed requirements and error tolerance differ.
Customer Web
- Keep purchase and reservation flows short and clear
- Show pre/post-payment state and cancellation/refund information in product language
- Keep site-scoped summary and purchase history aligned in my page
CRM
- Dense tables and bulk actions for repeated operations work
- Express permission failures, payment exceptions, and statistics rules in operator-friendly states
- Connect filters, exports, and status changes by task unit
POS
- Large touch targets and fast product selection for field use
- Prevent state damage with movement/edit locks during pending payment
- Handle failed-order recovery and terminal settings inside the work flow
Working Style
Working style
Reproduction, contract checks, small verification, and documentation sync are treated as part of development.
- Read the codebase and existing contracts first to narrow the change scope.
- Align shared state meaning across backend, customer web, CRM, and POS.
- Trace real callers, endpoints, and permission gates for high-risk payment, permission, and reservation flows.
- Run targeted tests and manual verification based on change risk.
- Record progress and follow-up work so the next operator can continue safely.