AI is making it much easier to build software.
That sounds like an obvious win, and mostly it is. But it also means I am competing with thousands of people who can produce a decent first version of the same idea. A working demo is no longer enough to make a product feel alive.
So what makes somebody trust that I will still be here after they try it?
The obvious answer is that the product should do what it promises. Nothing below rescues a bad core product. But once that part works, I think every app needs two visible habits: a changelog and a feedback loop.
1. Show that the product is moving
A changelog is not release-note paperwork. It is proof that somebody is still paying attention.
The Browser Company made this feel unusually human with Arc. The team showed what shipped, explained why, and made the process part of the product. You did not have to guess whether Arc was abandoned or whether a bug had disappeared into a support inbox. You could see the movement.
That matters even more for a small product. If I am asking somebody to install something new, trust me with their data, or change how they work, they are quietly asking:
- Is anybody maintaining this?
- Will the rough parts improve?
- If I report something, will a human see it?
A good changelog answers those questions with evidence.
It does not need to be a cinematic weekly video. A short entry that says what changed, why it mattered, and what still does not work is enough. The important part is the rhythm. Users should not have to investigate whether the product is alive.
2. Let people see what happens to feedback
A feedback form collects messages. A feedback loop shows what happened next.
Raycast does this well. People can request something, see whether others want it, and follow the request as it moves. The user is not only sending a message into a black box. They can see that the product has a relationship with the people using it.
This does not mean building everything users ask for. Users can be wrong, requests can conflict, and the product still needs a point of view. The useful promise is smaller:
- I will listen.
- I will show what I understood.
- I will be clear about what I am doing and what I am not doing.
- When something ships because people asked for it, I will close the loop.
That last part is easy to miss. If a request becomes a feature, link the changelog entry back to the request. Let the person who asked see the distance between their message and the thing that now exists.
Why these two belong together
A changelog without feedback can become a company congratulating itself. A feedback board without a changelog becomes a graveyard of requests.
Together, they tell a better story:
Someone asks. The team responds. The work becomes visible. The result ships. The person who asked can see what happened.
That is not marketing pasted on top of product development. It is product development made legible.
I am building Daylens in public, and this is a standard I need to hold myself to as much as anybody else. A quiet repository and a vague promise are not enough. If I want people to trust where the product is going, I have to show where it moved.
Products can fail. The people building them should still learn, return, and keep their promises visible.
CT