Most people start thinking about data after they launch something.
They build an app.
They publish a landing page.
They post on social media and say:
“I made this. Please try it and leave feedback.”
There is nothing wrong with that.
After launch, clearer data starts to appear.
Downloads.
Ratings.
Reviews.
Retention.
Churn.
User activity.
Maybe even revenue.
Those numbers matter.
But recently, I saw a different kind of product-building process from a creator building a small widget/app called Dorong.
Dorong is still in an early stage.
It is not a fully packed product with every planned feature already included.
And that is exactly what made the process interesting to me.
The creator is not waiting until everything is finished before learning from users.
They are validating the minimum version first, collecting VOC, organizing feedback, and using those signals to shape the next version.
That may sound simple.
But honestly, this is becoming rare.
A lot of people want to build fast.
A lot of people want AI to define the direction.
A lot of people want to launch first and check data later.
But Dorong reminded me of something important:
Data does not always begin after launch.
Sometimes, data begins before launch, with one small piece of feedback.
You can check Dorong here:
https://cantabilejack.github.io/dorong-landing/?utm_source=threads&utm_medium=social&utm_content=link_in_bio
I am not sharing Dorong only as an app link.
I am sharing it as an example of a creator building with feedback before launch.
The risk of waiting until launch
Launching an app is exciting.
But it is also risky.
Before launch, everything can feel clear inside the creator’s head.
The feature makes sense.
The use case feels obvious.
The interface looks understandable.
The value seems easy to explain.
But once real people see it, hidden questions appear.
Do people understand what the product is for?
Do they know when they would use it?
Do they feel curious enough to try it?
Do they understand the first screen?
Do they ask for something the creator did not expect?
Do they ignore the feature the creator thought was important?
This is one of the hardest parts of product building.
A product is not only what the maker built.
A product is also what users understand, expect, misunderstand, and actually use.
If you wait until launch to learn all of this, the data may come too late.
You can still improve the product after launch.
But some problems become more expensive after people have already formed their first impression.
That is why pre-launch feedback matters.
Dorong is still small, and that is the point
One thing I liked about Dorong’s process is that the creator is not pretending the product is already complete.
Dorong is being tested at a minimum-feature level.
Instead of trying to validate every big idea at once, the creator is focusing on early usability and the core experience first.
That is important.
Many early products fail not because the idea is bad, but because the maker tries to validate too many things at the same time.
Too many features.
Too many assumptions.
Too many target users.
Too many possible use cases.
When everything is being tested, nothing is being tested clearly.
Dorong’s current process feels different.
The creator is asking early questions:
What do users understand first?
Which part feels useful?
Which part needs more explanation?
What kind of use case appears naturally?
What kind of feedback repeats?
This is not a final success story.
It is something more useful:
A real example of early validation.
VOC disappears if you do not capture it
The creator told me something that made this case even more interesting.
They collect VOC through three main channels:
Text.
Phone calls.
Face-to-face conversations.
That may sound ordinary, but there is an important problem here.
VOC is fragile.
A message can disappear in a chat thread.
A phone call can become a vague memory.
A face-to-face conversation can fade after a few hours.
If you do not capture feedback quickly, it becomes hard to use later.
This is where the process becomes meaningful.
Instead of letting feedback disappear, the Dorong creator stores and organizes it.
They use Claude and a Notion MCP workflow to capture VOC quickly.
For phone calls or face-to-face conversations, they roughly write down the factual points and the conversation details into Claude.
For message-based feedback, they capture the text itself and process it.
They also use a Claude project with a service and marketing perspective, so the VOC is not just stored as random notes. It is processed in a way that can support product direction, positioning, and future updates.
This is the part I find rare.
It is not just asking for feedback.
It is building a feedback system before launch.
A comment is not automatically insight.
A reply like “This looks useful” is a signal.
A reply like “I would use this for my daily routine” is a signal.
A reply like “This part is confusing” is a signal.
A reply like “Can I test it?” is a signal.
But scattered comments are still scattered comments.
They become useful data only when the creator collects them, groups them, and looks for repeated patterns.
That is what made Dorong interesting to me.
The creator was not only receiving reactions.
They were turning those reactions into usable feedback before sending out a test version.
That is the key difference.
The value is not just “getting feedback.”
The value is turning feedback into the next decision.
Three ways people build today
Watching this process made me think about three different ways people build products today.
1. Trust the AI direction
This is becoming common.
A person asks AI what to build, which features to include, what the target audience might want, and how to position the product.
AI gives a clear answer.
That can be useful.
It can help people start faster.
It can organize messy ideas.
It can suggest possible directions.
But AI can also make a direction feel more certain than it really is.
A well-written answer is not the same as real user response.
AI can suggest a path.
But it cannot prove that people will care.
2. Wait for post-launch data
This is the more traditional way.
Build the app.
Launch it.
Measure downloads, reviews, ratings, retention, and usage.
This data is important because it comes from real users.
But it arrives after the product is already in the world.
That means the learning is real, but it can be late.
3. Build data before launch
This is the approach I saw in Dorong.
Show real usage.
Collect comments.
Capture VOC quickly.
Group feedback.
Look for repeated signals.
Adjust the product before wider release.
This does not replace post-launch data.
Downloads, ratings, and retention will still matter later.
But pre-launch qualitative data can reduce risk before launch.
It can help the product become clearer before more people see it.
The difference is the mindset
The biggest difference I saw was not technical.
It was a mindset.
Some people think:
“I will finish the product first. Then I will collect data.”
But another mindset is:
“I will collect signals first, so I can make a better product before launch.”
That second mindset is harder.
It requires patience.
It requires showing unfinished work.
It requires listening before everything is polished.
It requires sorting messy feedback.
It requires changing direction when the feedback reveals something uncomfortable.
But it also creates a stronger product-building process.
Because the creator is not only building from their own assumptions.
They are building with reality in the loop.
Personal data is not only numbers
When we hear “data,” we often think of dashboards.
Downloads.
Revenue.
Conversion rates.
Retention charts.
Those are important.
But for individual creators, early data is often smaller and softer.
A comment.
A repeated question.
A hesitation.
A feature request.
A message from someone who wants to test the product.
A pattern in how people describe the value.
This is qualitative data.
It does not look as clean as a dashboard, but it can be extremely valuable.
Especially before launch.
For a small creator, one good comment can sometimes reveal more than a hundred empty pageviews.
A few repeated questions can show where the product explanation is unclear.
A short phone conversation can reveal a use case that the creator did not expect.
That is why personal data matters.
It helps creators avoid building only from imagination.
Small products also deserve serious validation
One thing I respect about this process is the effort.
Dorong is still early.
It would be easy to say:
“I will validate later.”
“I will collect data after release.”
“I will ask users after I finish more features.”
But the creator is already building a validation loop.
That matters.
Small products are often treated casually.
People assume that only big companies need data, user research, VOC, or feedback systems.
I disagree.
Small products may need careful validation even more.
A large company can survive a wrong feature.
A small creator has less room for wasted effort.
A large company can run a big campaign.
A small creator needs to learn from every signal.
A large company can wait for thousands of users.
A small creator may need to learn from ten honest conversations.
That is why I think this kind of process deserves attention.
Not because every indie app needs a complex data system.
But because even small products deserve careful validation.
More creators should build like this
I wish more creators built this way.
Not because everyone needs to become a data analyst.
Not because every small project needs dashboards, BI tools, or complicated tracking systems.
But because more creators should learn to check their assumptions before they become too expensive.
Before launch, feedback can feel messy.
But messy feedback is still valuable if it is organized.
Before launch, comments can feel small.
But small comments can reveal real usage expectations.
Before launch, a product can still change.
That is exactly why early signals matter.
Dorong is still in progress.
That is why this case is interesting.
It is not a finished success story.
It is a live example of a creator trying to build with feedback, not only with assumptions.
I hope more people try Dorong
I also hope more people, especially outside Korea, get a chance to try products like Dorong.
Small independent products often carry something large platforms do not have.
They carry the maker’s daily attention.
They change through direct feedback.
They grow through small conversations.
They improve because someone is paying attention to the details.
That kind of effort is easy to miss.
But it is exactly the kind of effort that makes software feel human.
If you are building an app, a tool, a newsletter, a blog, or any small product, this is the lesson I would take from Dorong:
Do not wait for data only after launch.
Show real usage.
Listen carefully.
Collect the small signals.
Store feedback before it disappears.
Group what repeats.
Use it to make the next version better.
Personal data does not always begin with a dashboard.
Sometimes it begins with one comment.
And sometimes, one comment is enough to change the direction of a product.
Related Deep Dive on Dechive:
Data Analysis Beyond Business
Dorong landing page:
https://cantabilejack.github.io/dorong-landing/?utm_source=threads&utm_medium=social&utm_content=link_in_bio
