DONGYEOP KIM AI PRODUCT BUILDER

DONGYEOP KIM · AI PRODUCT BUILDER

I find overlooked problems and turn them into AI products that work in the real world.

I start with user behavior and broken workflows, decide what data, code, models, and people should own, then build, operate, and improve the complete product.

View selected workResume PDF (opens in a new tab)GitHub (opens in a new tab)
WorldLim learning world and stage-selection screen WorldLimOpen live product ↗ SajuBase screen for revisiting saved consultation insights SajuBaseOpen live product ↗ Dactoro simulated patient interview and clinical-note screen DactoroOpen live product ↗ Yorriro step-by-step cooking runtime screen YorriroOpen live product ↗
4live AI products built and operated 37,780learning-content items connected in one product ~15people using an internal AI workflow weekly 2M+views on one audience-led content piece

Selected work

Different problems required different systems.

These cases do not repeat one agent pattern. Each architecture follows the user, the decision boundary, and the cost of failure.

01Live product

WorldLim

Problem found
Reading definitions or asking an LLM isolated questions did not create a path through a concept's boundaries, misconceptions, perspectives, and applications. Creating that path still depended on skilled teachers and their time.
Key decision
I split the teacher's role into reviewed lesson data prepared ahead of time and a runtime tutor grounded in the exact material and learning state the user sees.

Concrete proof3,778 active bundles · 37,780 child content items

What you can inspectSee how that teaching model became sense-level learning units, a generate-review-repair gate, and a tutor grounded in the live screen.

  • Product data
  • Repair gate
  • Grounded tutor
  • Flutter
Read the problem-solving case Open live product (opens in a new tab)
WorldLim screen examining one word through Kant, Plato, and Jeong Jiyong
Generated and reviewed learning data inside the actual lesson flow
02Deployed internally · adopted by real teams

OnThePlanet Internal AI Systems

Problem found
Marketers with the most judgment to contribute were spending that time preparing data, while their best reasoning remained individual rather than reproducible across the team.
Key decision
After separating the workflows through interviews, I used one controlled call for fast analysis and durable artifacts plus human review where rationale had to survive across proposal stages.

Concrete proof~15 weekly users · survey pre-test from ~2 weeks to 1 business day

What you can inspectSee why four problems inside one company required AI systems of different sizes.

  • Workflow discovery
  • Data readiness
  • Human review
  • Adoption
Read the problem-solving case
03Private alpha · in development

Getsit AI

Problem found
GPT and Gemini turned the same request—organize this without compressing it—into different work, then each preferred its own style in a blind comparison.
Key decision
Instead of ranking models globally, Getsit fixes the user's priorities first and compares actual output behavior for that task.

Concrete proof10,277-character input · 3 live model runs · quality, latency, and cost

What you can inspectSee one 10,277-character source run compared across three models with evidence, latency, and cost.

  • Model fit
  • Intent rubric
  • Multi-model
  • LLM evaluation
Read the problem-solving case
04Open source · used for real work

Agent Computer

Problem found
Natural language made agents easy to delegate to, but longer work made progress, preserved intent, and repair points harder to see.
Key decision
Familiar apps, files, projects, and state preserve decisions, handoffs, approvals, and QA outside the chat.

Concrete proofPublic code · real research QA · runnable document walkthrough

What you can inspectInspect how file state, handoffs, and a pre-writing quality verdict changed real work.

  • Agent apps
  • File state
  • Handoff
  • QA
Read the problem-solving case View code (opens in a new tab)
Agent Computer structure: source material passes through agent apps into inspectable project files
Agent work made visible through apps, files, and projects
05Live paid service

SajuBase

Problem found
One product contained two opposite responsibilities: calculation had to repeat exactly, while consultation had to adapt to the user's current concern.
Key decision
TypeScript owns the calculation; the model interprets structured results, with memory, payment, and account recovery completing the service.

Concrete proof2-person team · paid operation · entitlement recovery

What you can inspectSee how deterministic domain logic and generative consultation become one operable paid product.

  • Deterministic core
  • AI consultation
  • Memory control
  • Payments
Read the problem-solving case Open live product (opens in a new tab)
SajuBase screen where users revisit topics discovered in consultation
Consultation memory under user control

A repeated way of working

I start with the moment the user or workflow breaks, not the technology.

  1. 01Observe the stop

    Look for abandonment, repeated preparation, quality variance, and failure records.

  2. 02Redefine the problem

    Separate a model problem from a data, workflow, or interface problem.

  3. 03Assign responsibility

    Decide what data, deterministic code, models, and people should each own.

  4. 04Build through operation

    Connect state, identity, payment, recovery, and deployment into the product.

  5. 05Repair from use

    Turn failures into better rules, evaluations, tools, and explanations.

How I got here

I moved from understanding people to building the AI products they need.

The technology changed. The starting point did not: find what people want, see where the current path breaks, and build a better way forward.

  1. 01

    2021-2022

    GrowingLab · Product Planning

    Read behavior as a product problem

    When users stopped exploring companies, I treated it as an information-priority and navigation problem rather than an acquisition problem.

    behavioral signal → problem definition → product requirement

  2. 02

    2023-2024

    LCK CRACKER · Product Manager

    Explain what people actually want to understand

    Fans already knew the result. I turned the decision or pattern they had missed into question-led shorts, analytical long-form, and a comparison metric.

    audience need → explanatory structure → repeatable format

  3. 03

    2024-2025

    Puzzle Systems · Researcher

    Learn where AI systems fail

    Phishing detection and construction-safety document generation showed me that models, data design, retrieval, evidence, and human review had to form one system.

    separate the responsibilities of models, data, evidence, and people

  4. 04

    2025-present

    OnThePlanet · BI Team PM / Independent AI Products

    Turn discovered problems into working AI products

    I built internal systems from workflow interviews and took multiple AI products from definition through full-stack implementation, deployment, and operation.

    problem discovery → system judgment → implementation → iteration from use

View English resume (opens in a new tab)

Built and operated

I put generative behavior inside complete product lifecycles.

These are not isolated demos. Users can start, preserve state, recover from failure, and return to a working product.

Before AI

I was already studying people before I built AI products.

Long before my current AI products, I was already turning behavioral data and recurring audience questions into product structures and explanatory formats.

LCK CRACKER

Fans wanted the perspective they had missed, not the score they already knew.

I turned recurring questions in comments and audience response into short-form hooks, long-form analysis, and a gold-acquisition metric.

  • 2M-view short
  • 370K-view long-form
  • contributed to 5,000 subscribers in 6 months
Read the problem-solving case Open channel (opens in a new tab)

GROWINGLAB

I read stalled exploration as an information-architecture problem.

I redesigned priority and comparison context in a company-analysis product, then checked behavior after launch.

  • company searches per visit +80%
  • user engagement +117%
  • average engagement time +67%
Open live product (opens in a new tab)

Writing

I turn product decisions into ideas other builders can use.

01

LLM Output Is Not Yet Product Data

Why are fluent prose and valid JSON still insufficient?

02

When Schema-Valid Errors Corrupt Product State

Where should structurally valid agent output be stopped?

03

What an LLM Must Not Know in Synthetic Survey Pre-Testing

Why can more information make a synthetic respondent worse?

Work together

I am looking for ambiguous problems that need to become working products.

If the work requires understanding users, choosing a defensible system boundary, and improving the result from real use, I would like to talk.

Email GitHub (opens in a new tab) Resume PDF (opens in a new tab) Writing (opens in a new tab)