Blog in English

Recently, I came across a team building a personal finance app that has gained quite a bit of attention. Their marketing is strong. They communicate clearly, tell a compelling story, and project a lot of positive energy. Watching their content, you get the sense that this is a team that knows how to talk about what they are doing.

But when you look at the product itself, there is a noticeable gap. The app is not yet easy to use, the flows feel rough, and many parts are still unpolished. As a result, their posts are filled with criticism, sometimes harsh: “the idea is outdated,” “the market is already saturated,” “this will fail anyway.”

At first glance, it is easy to label this as a classic case of marketing outperforming the product. But I think the situation is more nuanced than that.

The argument that “there are already too many expense-tracking apps” does not mean there is no demand. In reality, many people around me still track their spending in Notes, Excel spreadsheets, or even on paper. That does not suggest the problem has been solved. It suggests the existing solutions have not fully fit the way people actually live.

Users do not hate old ideas. They hate old experiences. Most people do not care how many similar apps exist, how long the category has been around, or whether the concept is revolutionary. What they care about is simple: is this easier than what I am doing now? Does it reduce friction? Can I stick with it?

Web browsers are a good analogy. Chrome is already very good, yet there are still countless other browsers, many of them built on the same engine with only small differences. That is not irrational. A slightly different approach, aimed at the right group of users, can be reason enough to exist.

What is interesting about this team is that they chose to build in public. They share the process while the product is still rough, still incomplete, still open to criticism. The price they pay is early judgment. The return they get is something many well-built apps never achieve: attention, real interaction, and a user base far beyond their initial expectations.

At an early stage, this matters a lot. Many products do not fail because they are bad, but because nobody ever notices them. This team accepted pressure early in exchange for visibility, real feedback, and real usage data. Strategically, that is not a naive decision.

Not all criticism is negative. Emotional, low-effort comments help amplify reach. Concrete complaints about usability or flow are valuable signals. The most dangerous outcome is not being criticized, but being ignored.

This reminds me of a line from The Matrix that has always stuck with me:

"The first Matrix I designed was quite naturally perfect, it was a work of art, flawless, sublime; a triumph equaled only by its monumental failure."— The Architect to Neo

The first Matrix failed not because it was poorly designed, but because it was too perfect. A world without conflict, without flaws, without friction was something humans could not accept. Later versions intentionally allowed imperfections to exist—not out of weakness, but because imperfection was a requirement for the system to function.

Products work in much the same way. Something that is overly polished, overly controlled, and closed to participation can feel less real than a product that is visibly growing, changing, and being shaped in public.

Of course, the line is thin. Intentional imperfection is not the same as carelessness. Building in public is not an excuse for poor quality. It is about being honest about what is unfinished, while still maintaining control and direction.

A familiar example is Apple. Every time a new iPhone is announced, it is immediately criticized, mocked, and turned into memes. The design has not changed. The features are incremental. “Apple has lost its creativity.” The same comments appear year after year.

And yet, those reactions themselves turn the launch into a global event. It becomes almost impossible not to know that Apple has released a new iPhone. Being criticized, even mocked, is still far better than being ignored.

In the end, I do not think this story should be judged by whether the app ultimately succeeds or fails. The deeper lesson is this: being criticized early, while being seen early, can be a far stronger position than quietly building something good that no one ever discovers.

Products can be improved. UX can be redesigned. Ideas can pivot.Attention and early users, once missed, are much harder to recover.

Like the Matrix, imperfection is not always a failure. Sometimes, it is what makes a system believable, participatory, and capable of evolving.

I shared my app TimeMate with a screen demo, but everyone kept asking about the wallpaper 😅 so here it is!

Horizontal Screen

4K (3840x2160)

2K (2560x1440)

Full HD (1920x1080)

Vertical Screen

4K (2160x3840)

Full HD (1080x1920)

Preview

Besides releasing the app on the App Store, submitting it to Homebrew’s main branch was a completely new experience for me. Thanks to a user’s suggestion, I learned that getting listed in Homebrew’s official installation database actually requires meeting a certain set of standards. I’ve been using Homebrew for years, yet somehow never paid attention to how it really works.

A quick side story: when I shared the app in a group the other day, someone left a comment like, “always tinkering with some tiny tool.” I honestly didn’t know how to respond. But the surprising part came from a different place — this tiny little app actually received a donation. The amount wasn’t big, but the fact that someone voluntarily contributed without asking for anything made me feel like this app is useful not just for me, but for others as well.

It’s true that I “tinker” a lot — the kind of stuff many people wouldn’t bother doing. But everything I build comes from a real need of my own, and I use these apps every day. Nowadays, if a product isn’t labeled with “AI” or “Blockchain,” it’s considered “out of meta.” But I think even in a world where humans can build rockets for space tourism, there are still people making needles and pencils. For me, as long as something I build shows up at the right moment and solves someone’s problem, that’s already more than good enough.

I’m not sure if anyone else feels the same, but whenever I work on a product, I’m always excited about building the “core” features. The moment I have to deal with non-functional stuff like onboarding, landing pages, or user guides… my energy drops instantly 😅

I’m not great at UX writing, and I’m not the type to confidently “sell” things with fancy words either. But if I write too technically, it becomes dry and boring. So I always end up stuck somewhere between those two extremes: clear – concise – engaging – but still accurate.

Sometimes I scroll through other solo indie projects and see how meticulous some folks are with their onboarding flows and landing copy. Every line is polished, every message feels intentional. And honestly, I truly admire that.

Meanwhile, I’m usually the kind of person who just wants to jump straight into coding. But when it comes to explaining features or writing a simple intro, I can spend ages trying to craft just a few sentences.

Maybe it’s a common weakness among developers: we’re great at solving problems, but not always the best at describing them in words. I’m trying to slow down and put a bit more care into the “non-code” parts. After all, users don’t read our code — they read our words.

In this post, I'll be sharing with you the Pomodoro Technique, a time management method that can help you stay focused and productive.