LEE SANGINN

AI-Native Product BuilderProduct Generalist

I connect product planning, design, engineering, growth, and experimentation to turn ideas into working products.

Channels and contact

About

I started in service planning.

I learned to find problems through user research, design service flows and policies, and carry a product through launch with a cross-functional team. With a nine-person team, I launched Trippixel, an AI travel coordination planner, then used GA4, user interviews, and VOC to examine the gap between the plan and real use.

I did not want to stop at the plan.

I learned design and code so I could test ideas myself, and I am expanding into marketing, game development, AI systems, and developer tools. The point is not to touch many fields lightly. My way of working is to connect the roles a problem needs and carry the idea as far as I can into a real outcome.

I keep the decisions behind the work.

That is why I describe myself as an AI-Native Product Builder and Product Generalist. I treat AI less as a substitute for judgment and more as a tool that expands how I research, design, build, and validate. onebuilderlog keeps not only the finished work, but also the decisions, failures, and lessons behind it.

Profile snapshot

4 projectsResearch-led projects

1 launchPublic launch

2 projectsSolo PM projects

8-9 peopleCross-functional team size

Education

Seoul Cyber University

B.S. in Computer Science, in progress

2026.03 - PRESENT

Jeju Halla University

B.A. in Social Welfare

2018.03 - 2023.02

Training

goorm × Kakao Product Management Bootcamp

Completed

2025.09

Credentials

GAIQ

Google Analytics Individual Qualification

2026.02

What I can contribute

Problem discovery

I turn user research, interviews, and VOC into problems and hypotheses.

Product design

I turn service flows, policies, and priorities into actionable slices.

Measurement

I connect GA4 and user feedback to the next product decision.

Direct implementation

I build verifiable product surfaces with Astro, TypeScript, Python, and Codex.

Now learning

Computer Science

I am studying the technical foundations needed to implement products directly.

Product Planning & PM

I am deepening how I define problems, set priorities, and make post-launch product decisions.

Data-informed Decision Making

I am learning to turn user behavior and product metrics into better decisions.

AI Products & Developer Tools

I am building and validating products and tools for people working with AI.

Interests

01
How does a product reach real use?
02
How far should we delegate work to AI?
03
How do different disciplines come together in one product?
04
How far can one person build with AI?

Selected work

Four projects built from research and validation

Public launch2025.11 - 2026.05

Trippixel

AI travel coordination planner

Why: It started with the burden that travelers with different preferences face while collecting information and reaching agreement before a trip.
Core problem: Saving places, sharing opinions, and confirming an itinerary were scattered across tools, concentrating coordination work on one planner.
Role: Solo planner/PM · 9-person team
Evidence: 64 survey responses · 5 interviews · Public web launch on 2026.03.18 · GA4: 65 users / 91 session starts
What remains: The moment that earns repeat use remains to be validated.

Open live product

Unreleased prototype2025.08 - 2025.09

Moyeohaeng

Real-time collaborative travel dashboard

Why: It was designed to reduce the information and decision burden that falls on one trip organizer as the group grows.
Core problem: Place collection, opinion sharing, and itinerary editing were split across multiple tools, making collaborative planning difficult.
Role: Solo PM · 8-person team
Evidence: 87 survey responses · 11 interviews · User testing

Request case material

Prototype validation2025.07 - 2025.08

Baemin One-person Household Case Study

Independent, unofficial product case study

Why: The proposal explored a shorter path for one-person households to save trusted meals and restaurants and reorder quickly.
Core problem: Reorder and favorite flows had low visibility, and saving a restaurant was not connected clearly to returning and ordering again.
Role: APM · 4-person PM team
Evidence: Interviews and usability tests · 2 prototype validation rounds

Request case material

Research prototype2025.06 - 2025.07

Dajeongi

Caregiver reassurance signal service

Why: It was designed to reduce caregiver anxiety around missed calls without turning reassurance into constant surveillance.
Core problem: Repeated calls created anxiety for caregivers and a sense of surveillance and relationship conflict for older adults.
Role: PM / Team lead
Evidence: 6 caregiver interviews · Prototype validation with 4 participants

Request case material

Independent AX workflow studies

Three studies that turn work judgment into executable rules

These are independent studies that use public materials to bound a problem, then make the human decision boundary, inputs, rules, and verification explicit.

ARCHIVE STATUSThis page contains only builder-authored summaries and verification scope. Submission PDFs with third-party reference captures are withheld pending a rights review.

01MyRealTrip

Independent study · locally verified

A rule-based evaluation for cancellation-recovery exposure policy

Policy QA · experiment readiness 2026.06

Problem boundary: Showing alternatives after cancellation can help, but repeating the cancellation risk, raising price sharply, or lacking booking evidence can damage trust and increase support risk.
Operating model: It separates decision-time inputs from post-outcome data, then uses six risk rules to classify candidates as expose, needs_review, or suppress and the policy as ship, revise, or hold.
Local proof: It passed 5/5 unit tests across mock scenarios and a public MCP snapshot. When public product evidence was insufficient, it returned the whole policy to hold.
Source scope: Public MyRealTrip technical posts and API documentation bounded the problem. No customer, payment, or internal log data was used.
Not claimed: It does not claim MyRealTrip internal-system access, production deployment, or a lift in revenue or rebooking.

02Musinsa

Independent study · synthetic-fixture verified

A partner-growth bottleneck diagnosis that exposes both data boundaries

Two-sided diagnosis · data-request loop 2026.07

Problem boundary: Brand context sits with the brand while exposure and conversion signals sit with the platform, so one side alone cannot conclusively diagnose a growth bottleneck.
Operating model: It compares a brand packet and platform packet at product level, returning one of seven bottlenecks with confidence, missing data, and prohibited conclusions.
Local proof: It matched 8/8 expected outcomes across synthetic fixtures covering seven bottlenecks and an insufficient-information case, while checking the boundary between thresholds and observations.
Source scope: Public Musinsa organization and newsroom material bounded the problem. No real brand or platform data was used.
Not claimed: It does not claim Musinsa data access, partner adoption, or real brand-growth impact.

03KakaoPay

Independent study · demo-policy-pack verified

A PR review that fixes a work manual into an approvable policy pack

Policy governance · evidence-based review 2026.07

Problem boundary: As AI-generated changes accelerate, consistently applying security, privacy, and operations criteria scattered across documents and expertise becomes the bottleneck.
Operating model: Rule candidates carry source quotes and line numbers, become a policy pack only after human approval, and surface only exceptions or missing evidence as human_review in a PR.
Local proof: Across four author-created demo rules and six fixture PRs, it recorded 1.000 rule coverage, status accuracy, and reproducibility, with zero hallucinated rules.
Source scope: Public KakaoPay technical material and GitLab research bounded the problem; the policy pack and fixtures are author-created demos.
Not claimed: It does not claim access to KakaoPay internal manuals, code, or security criteria, production adoption, or improved real PR quality.

GitHub archive

I am expanding what I can build directly.

Only public repositories are projected at build time. Missing purposes are left unclaimed.

Vibebuilder

Why: I built it to keep context, validation, and review repeatable across long-running AI development work.
Core problem: A single prompt cannot reliably preserve context and validation discipline across a long-running project.

iamsolazyfordesign

Why: I built it to turn design references into evidence-bound implementation contracts rather than surface-level imitation.
Core problem: AI coding tools can copy surface style, invent unseen behavior, and miss the target design system.

Zeus

I built it to keep AI-agent actions inside human-defined authority and approval boundaries.

PythonPolicy GatesLocal-first

View on GitHub

packly-developer-preview

I built it to route only the rules and context each AI coding tool needs for the current task.

ShellCLIMCP

View on GitHub

apollo

I built it to keep an image-to-3D asset workflow local and under Codex control.

PythonCodexLocal-first

View on GitHub

View all repositories

Let’s talk

I want to work with a team that connects problem discovery, design, implementation, and validation.

Email is the fastest way to reach me about roles, collaboration, or project proposals.

Email me GitHub LinkedIn Return to profile