About

Hi, I'm ddoong-guri.

At a glance

Role
B2C product developer, currently at DocentPro (a travel app)
Focus
Consumer products, growth, and retention
Built
A campus app backend (UOSLIFE), a notice chatbot (UosAsk), a PX stock and pickup service for soldiers (Mili-Stock), and a travel app (DocentPro)
Writes about
Products I have built, consumer app teardowns, retention, and working with AI

I like building products for ordinary people, and what I care about most is what happens after launch: do they come back? I worked on the backend of my university's student app, built and ran a notice chatbot that students actually used, took a service for soldiers from interviews to a proposal to the military welfare agency, and now build a travel app. I work with AI agents every day to get from an idea to a working feature.

What I want to build

Consumer products people open on an ordinary day, not only when they need them.

Here I write about the products I have built, take apart consumer apps I use, and share how I work with AI.

Things I have built

Different users, the same question: will they come back?

  1. 01

    UOSLIFE

    The University of Seoul student app (timetable, notices, campus services).

    Backend: real-time chat for the campus matching service, club recommendations, a game scoreboard API
  2. 02

    UosAsk

    A notice chatbot for University of Seoul students. It ran with real users and was later folded into UOSLIFE.

    Project lead, backend and infrastructure
  3. 03

    Mili-Stock

    Lets soldiers check PX stock and reserve items for pickup. Pitched to the Armed Forces Welfare Agency, which reviewed it but did not adopt it.

    PM and backend, from interviews to the proposal
  4. 04

    DocentPro

    A travel app that turns places from short videos into a map and a trip.

    Engineer: place extraction, hotel pricing and booking

How I work

  1. 01

    Test whether something is really impossible before finding a workaround.

    Most walls I have hit turned out to be assumptions. One direct test is cheaper than a week of workarounds.

  2. 02

    Measure how often it happens before fixing it.

    I want to know how often a problem happens and to whom. A fix for a rare case should not change what everyone uses.

  3. 03

    Decide first, then write the code.

    Cause, scale, options, decision. Code is the last step, not the way to think out loud.

  4. 04

    AI agents do the work; I decide what matters.

    I work with several AI agents every day. They work quickly; I decide what matters.

Elsewhere

Or just say hi →