I shipped ddodol 1.0 as a small pet rock app.
The first version starts with a simple loop: shape a rock with your finger, give it a face, choose its color and material, name it, pick one small prop, and place it in a room. From there, the rock can react. Tap it and it gets surprised. Pet it and it feels ticklish. Close the app and come back whenever you want.
That sounds almost too small to write about.
But that was the point.
A small app is not automatically a simple app. ddodol 1.0 was shaped less by everything I could add, and more by what I decided the app should not become.
I did not want it to become a social feed.
I did not want it to become a ranking system.
I did not want it to become a streak machine.
I did not want it to become a mood tracker wearing a cute face.
I wanted the rock to react, but never demand.
That became the product rule for the first release:
The rock can respond to you, but it should not ask anything from you.
The First Loop
The first interaction in ddodol is not account creation. It is not profile setup. It is not a dashboard.
It starts with a rock.
The first loop looks like this:
- Shape the rock with your finger.
- Add a face.
- Choose its color and material.
- Give it a name.
- Pick one small prop.
- Place the rock in a room.
- Tap it and watch it get surprised.
- Pet it and watch it feel ticklish.
- Close the app and come back whenever you want.
This loop mattered because it defined what kind of app ddodol was allowed to become.
If the first screen asked for login, the app would feel heavier. If the first loop asked for daily check-ins, the app would become a tracker. If the first reward was a streak, absence would start to feel like failure. If the first social feature was a feed, the rock would become something to perform with.
So I kept the opening loop physical and small.
Make a rock.
Meet the rock.
Let it react.
Leave without guilt.
What I Left Out of 1.0
The most important product decisions in ddodol 1.0 were not only the things I built. They were also the things I left out.
There is no login.
There is no account system.
There is no feed.
There is no matching.
There are no rankings.
There are no streaks.
There are no scores.
There is no public profile.
Each of those features would have been reasonable in another app.
A login would make sync easier. A feed would make sharing more visible. A ranking system would create structure. Streaks would improve retention. Scores would create progression.
But every one of those features changes the emotional contract of the app.
A streak says, “You should come back.”
A score says, “You should improve.”
A feed says, “You should show something.”
A ranking says, “Someone is ahead of you.”
A public profile says, “This is part of your identity.”
That was not the feeling I wanted.
ddodol is not supposed to make the user prove that they are doing something. It is supposed to be a small thing that waits.
Notifications Did Not Make 1.0
Notifications did not make 1.0.
Not because reminders are always wrong, but because they were not the biggest risk in the first release. A reminder to visit the rock could wait. A white screen that makes someone delete the app, and the rock with it, could not.
So ErrorBoundary came first. More on that below.
Local notifications may still make sense later, if they stay on-device and gentle.
Why the Rock Never Asks for Anything
The rock is not inactive.
It reacts.
If you tap it, it gets surprised. If you pet it, it feels ticklish. It can sit in different rooms. It can be part of small games. It can ride a bike through Paris. It can appear in an album. It can have wishes and neighbors.
But it should not make demands.
That difference is important.
A demanding pet app asks to be fed. A demanding game asks for daily progress. A demanding social app asks for updates. A demanding habit app asks for consistency.
ddodol should not do that.
The rock does not get angry because you left. It does not punish you for missing a day. It does not turn your absence into a broken streak. It does not ask you to optimize anything.
It can be touched, shaped, named, and visited. But it should not make you feel like you owe it something.
That was the line I tried to protect in 1.0.
Things That Broke While Building It
The calm feeling of ddodol depends on a lot of small implementation details.
The first one was shaping.
At first, the rock did not really follow the user’s hand. A gesture changed one point at a time, and the touch position was slightly off. That made the interaction feel disconnected. The app was asking the user to shape something, but the shape did not feel like it was responding to the finger.
The fix was to make shaping feel more like a brush.
Instead of moving one point directly, the brush needed a radius. Nearby points should move more, faraway points should move less, and the falloff should feel soft. Adding Gaussian falloff made the rock deform more naturally, and showing the change while dragging made the interaction feel alive.
The second problem was gesture overlap.
Tapping, petting, and moving are all touch gestures. If the app only looks at distance, it is easy to confuse them. A small drag can look like a tap. A tap can accidentally become movement. Petting can compete with moving.
The fix was to judge the gesture in stages:
First, how long was the press?
Then, how far did the finger move?
That made the interactions easier to separate. A tap could stay a tap. A pet could feel like a pet. Moving could be treated as moving.
The third problem was less visible but more important: failure handling.
The rock is stored on the device. That makes the app feel private and simple, but it also changes what failure means. In a web app, a blank screen often has an obvious response: refresh the page. In a native app, a blank screen can feel like the whole app is broken.
If the screen goes blank, the only thing a person can do in a native app is delete it, and deleting the app deletes the rock.
So instead of a blank screen, ddodol shows a way to restart, plus a button that copies the saved rock to the clipboard.
That is not a flashy feature. But for an app that keeps everything on the device, it is part of the product. If the app asks someone to make something personal, it also has to give them a way to protect it when the UI fails.
Permissions in 1.0
I also avoided asking for large permissions in 1.0.
A small app should be careful about the moment it asks for access. Permission dialogs are not just technical steps. They change how the user feels about the app.
In 1.0, I did not want to ask for photo library or microphone permissions just to support one cute image flow. If the app is supposed to feel light, it should not immediately ask for access that feels bigger than the feature.
This may change over time, but only narrowly.
For example, saving an image directly can justify add-only photo permission on iOS. The app can put a photo in your library, but cannot look at it.
That is different from asking for broad media access, microphone access, or unrelated permissions.
The rule is not “never request permission.”
The rule is to make the permission smaller than the user’s trust.
Keeping Settings Out of the Room
Another small decision was where configuration belongs.
It would be easy to put language switching or other controls directly on the main screen. That would make them visible and convenient.
But the main screen in ddodol is not a control panel.
It is the room where the rock lives.
That distinction helped me decide where settings should go. Language configuration belongs in Settings, not on the emotional surface of the app. The home screen should stay focused on the rock, the room, and the tiny interaction between them.
This is a small layout decision, but it protects the feeling of the product.
The more the home screen looks like software, the less it feels like a quiet place to visit.
Why the Share Link Is Small
ddodol does have sharing, but the share link is intentionally limited.
It carries the rock’s shape, its name, and how many hands it has passed through.
Nothing else.
The number of days together, wishes, and personal history stay out of the share payload. Those details belong to the person who made the rock. If sharing carried everything, the link would start to feel like a profile, a history export, or a social graph.
That is not the goal.
The link should say:
Here is my rock.
Not:
Here is my account, my progress, my wishes, and my emotional record.
That is why a rock received for the first time says: “Someone shaped this. Only the shape came along.”
A rock that has passed through several people says: “Passed through N hands. Only the shape came along.”
The relay count shows that the rock traveled, but the private parts did not.
A received rock can sit in your room for a while, but it cannot become your rock. There is no path for someone else’s rock to become yours.
That is another reason the share link stays small.
What This First Version Taught Me
The first version of ddodol taught me that small apps still need strong boundaries.
It is easy to make a pet rock app bigger.
It is harder to keep it quiet.
Every obvious feature comes with a product direction attached to it. Login points toward accounts. Feeds point toward performance. Streaks point toward obligation. Rankings point toward competition. Notifications point toward attention.
Some of those may be useful later. But none of them should enter the app accidentally.
For ddodol, the first version had to prove that the basic loop could stand on its own:
Shape a rock.
Name it.
Give it a place.
Let it react.
Come back when you want.
That is the foundation.
The next question is what happens when the user stays away.
In Part 2, I want to write about moss: how to let the rock change while the user is gone without turning absence into guilt.
Because even when the app changes, the rule should stay the same:
The rock can react.
It should not demand.