@ GS칼텍스2024Full-Stack
GS Caltex VOC AI Dashboard
Sole architect and engineer of the VOC AI Dashboard, manual review replaced by 1,000+/day auto-classification across 4 integrated channels.
View details
AI Product Engineer
★ Case 04 / 5Product Engineer Donghyun Kang
Come Visit the Market: Traditional Market Delivery
The app was built; couriers were short, so in the end I went out and delivered myself.
(주)마켓트리Backend2019.12 ~ 2021.01
01.Discover
Good code was getting written; a good product was not.
My first company was a startup. I was a junior backend on a traditional-market delivery platform, and back then I believed that writing good code made you a good developer. Designing in the meeting room and coding in front of a monitor — that was all I knew of dev work.
On launch day, orders came in faster than expected. There were not enough couriers to handle them. The CEO's call was firm — "Even the developer goes out and delivers right now." Honestly I was a little disappointed at first. I wanted to handle bigger systems, fancier tech, and a traditional-market delivery app was not the picture I had in mind. But once I put on a helmet and went into the market, there was a scene the meeting room had never shown me.
Field notes
Note 01
There was a shop where the notification never stopped
In one shop the new-order alert went off once and never turned off — the meeting room had never surfaced that bug.
Note 02
The owner did not know how to turn it off
The screen was hard to read, the dismiss flow was opaque, and more than a few owners were stuck on it.
Note 03
These were users who could not reach the support channel
They were not the kind of users who would file a ticket — we never heard about it, and the bug was bothering them every day.
02.Build with AI
Just writing what product hands you — that alone is not what makes a developer.
Decision 01
Before coding — start with why
Whatever I was about to build, I started by looking at what business impact the feature was supposed to produce. The picture came before the code.
Decision 02
Start with how it reaches the person using it
How it actually reaches the person on the other end — I sketched that before writing code. The code came out of the sketch.
Decision 03
Assume the user cannot reach support
Like the shop owners in the market alley, some users will not actively file a problem. I built that into the assumption layer of the work — we have to go and find it.
Decision 04
"Who is standing behind this code" — the first question for any new feature
Picturing the market alley, I started every new feature with the same question. That one line became the first question for everything I built after.
03.Prove with metrics
Not measured in numbers — measured by how you approach the work.
Realization
Code → product
From someone who writes good code to someone who sees what the product is actually for
Habit
Start with why
Business impact and user path before any code
Assumption
Users who cannot reach support
Go and find them on purpose
The question
"Who is standing behind this code"
The first question for any new feature
What this case is really about
“One screen used by one shop owner in a market alley became the first question I ask before any new feature.”
Discover
Put on a delivery helmet and walked the market alleys. Saw a notification bug the meeting room had never surfaced, and shop owners who could not reach the support channel at all.
Build
Started every new feature by asking "who is standing behind this code" — sketched the why, the business impact, and the user path before writing any of it.
Prove
From then on, every new feature started in the market alley — the shift from "writes good code" to "sees what the product is actually for".
Linked principlesEvidence-DrivenOwnership
App Showcase
Real screens, in production
What happens when product, design, dev, and ops all run through one pair of hands.
More work
