Two people started a project. Neither connected an AI. That was useful feedback.

오승현 — Thu, 03 Sep 2026 05:03:16 +0000

I put ProductChaengi in front of real users and watched the first two people verify their email and create a project.

Then both stopped before connecting an AI.

That is a tiny sample, so I am not going to pretend it proves why they left. But it did show me exactly where I still have no evidence: the jump from "I have a project" to "I should connect another tool."

I had been leading with the most technical part of the product. An AI can reuse work it has already checked, changed files can invalidate only the related checkpoints, and the next session can start with a much smaller slice of context.

That is useful later. It is not a good reason to begin.

The actual problem starts earlier.

A PRD gets written. A feature spec changes a week later. The user flow still reflects the old decision. Screens are drawn from a mixture of both. Test cases arrive at the end, and implementation becomes another interpretation of what the team meant.

Nothing is exactly "missing." The problem is that nobody can tell which decision is current, how one artifact led to the next, or where a change should travel.

ProductChaengi is meant to keep that chain together:

PRD → feature specs → personas → user flows → screens → design system → test cases → implementation review.

Each step can be drafted with the tools people already use, but a person reviews it before it becomes the current version. If an earlier decision changes, the downstream work should show what needs another look instead of quietly drifting apart.

The code checkpoint feature belongs at the end of that story. Once someone is working with an AI on implementation, it can avoid re-reading unchanged work and focus on the features affected by a change. Helpful, yes. But it only matters after the product decisions are worth carrying forward.

So I am changing how I explain and measure the product.

The first useful moment should not be "AI connected." It should be something closer to: "I can see one reviewed product decision and what it affects next."

Only after that should connecting an AI feel like a shortcut rather than setup homework.

The next thing I am watching is not raw sign-up count. It is whether someone can create one artifact, review it, and understand why the next artifact is connected to it. If that does not happen, more automation will not rescue the onboarding.

If you build products with AI tools, where does your context usually break first: PRD to design, design to tests, or tests to implementation?

I am building this in public here: https://product.chaengi.com/r/dev

I was not losing product docs. I was losing the current decision.

오승현 — Mon, 31 Aug 2026 05:35:51 +0000

I kept blaming my notes.

A PRD would start in one place. The user flow would move to a whiteboard. Screen decisions ended up in a design file. Test criteria were buried in an AI chat. Nothing was exactly missing, but by implementation I could no longer answer a simple question: which decision is current?

That was the real reason I started building ProductChaengi.

The problem was the handoff

Most tools help create one more artifact. That part has become much easier with Codex, Claude, and ChatGPT. What did not get easier was carrying a reviewed decision into the next stage.

A feature spec might change without the user flow changing. A screen might be approved while the test case still reflected the old behavior. Then an AI coding session would start with whichever document happened to be easiest to paste.

I did not want another chat window. I wanted one project where the PRD, feature specs, personas, flows, screen designs, design system, test cases, and implementation review could stay connected. AI can draft each part, but a human decides which version becomes the current standard.

One detail I nearly turned into the whole pitch

I initially talked too much about preventing an AI from reading the same code again. It is a useful feature: a checked scope can be reused only when its file manifest still matches, and changed or directly related areas go back to review.

But that is not the whole product. The bigger job is making sure the product decision made during planning is still visible when implementation is being reviewed.

There is also a boundary I wanted to keep clear. ProductChaengi does not watch a repository by itself and does not store source contents. The connected agent calculates and sends the manifest used for comparison.

What is live, and what is not proven yet

The end-to-end artifact flow, human approval, and change-aware checkpoint behavior work in isolated verification. The public product is live.

What I do not have yet is evidence from enough outside users to say where this saves the most time. I am especially curious about solo builders and small teams that use more than one AI tool.

If that sounds like your workflow, what falls out of sync first: the PRD, the screen, the test criteria, or the implementation itself?

ProductChaengi: https://product.chaengi.com/r/dev

Disclosure: I used an AI assistant to help edit and publish this post. The product decisions and experience described here are mine, and I reviewed the final text.

DEV Community: 오승현

Two people started a project. Neither connected an AI. That was useful feedback.

I was not losing product docs. I was losing the current decision.

The problem was the handoff

One detail I nearly turned into the whole pitch

What is live, and what is not proven yet