the joy of building

As a kid, I loved playing Minecraft.

It’s this infinite, open-world game made out of blocks. You can break almost anything and rearrange it somewhere else. There are caves to explore, items to craft, and monsters that come out at night. The game has no real goal, so the player can decide what they want to do.

I remember how excited I felt every time I created a new world. I would spawn somewhere, look around, and start imagining. A house on that hill. A bridge over the river. A village in the valley with farms, paths, and a harbour. Then I would start gathering materials and placing blocks. And pretty quickly I would realise how long it would take to build all the things I imagined.

Most of my ideas never got finished. I lacked the patience. At some point I would always start thinking:

Do I really want to spend this much time building something inside a video game?

Years later, vibe coding is giving me a similar feeling of excitement to the one I had playing Minecraft. Except now, the time problem seems to be gone.

Projects that would previously have needed months and several developers can now be built within a day. An AI-native CRM, an app for creating moodboards, or any other idea can be turned into working software with a few unpolished prompts.

The first few days of those projects are usually a lot of fun. There is an idea in my head, I can see it taking shape, and every hour something new appears. It feels a lot like starting a new Minecraft world.

Then, about a week in, something changes.

The basic functionality is there and the product starts to work. The project reaches a point where I have proven to myself that it can be built.

This is the moment where my excitement fades.

Instead of asking myself whether I really want to spend this much time building something, like I did in Minecraft, another question comes to mind:

What is the point of building something nobody uses?

the joy comes from building for others

The initial excitement of building something comes from having an idea and starting to see it take shape. But the joy, at least for me, comes from seeing somebody else use it.

I think this is why I spent the last three and a half years building CareMates without losing the joy of working on it.

We have an idea for a feature, we build it, we ship it, and very quickly hear from our users whether they like it or not. Sometimes they love it. Sometimes they don’t. When they don’t, we change it and try again.

I think this process taps into a deeply human wish for recognition. Receiving a compliment about a feature, the user experience, or some small detail I’ve spent a lot of time thinking about feels incredibly rewarding.

But you only get that when somebody actually uses what you made. You do not get it from building something that you keep only for yourself.

Recognition, however, is only fuel to keep going. The real value comes from feedback. Once somebody uses what you made, they show you where they struggle and what they wish for.

And that kind of feedback takes something vibe coding cannot really compress: time.

time never really disappeared

Coming back to vibe coding. At first, it felt like it had removed the biggest constraint I always associated with building: time.

To build something, you need resources. Skills, people, money, tools, and enough time to bring everything together. Vibe coding changes this dramatically. One person can suddenly do work that previously required several skilled people and much more time.

But the more I think about those resources, the more they seem to come back to time as well.

Justo Gallego might be the most extreme example of this. In 1961, he started building a cathedral outside Madrid largely by himself. He had no formal training as an architect or builder, limited resources, and worked with whatever materials he could get his hands on. He kept building for around sixty years, until his death in 2021.

What fascinates me about his story is how many of the resources we normally associate with a project of that scale were missing. No large team, no big machines, no architectural degree. What he had was an extraordinary amount of time.

Sixty years can compensate for a lot.

Skills are time spent learning. A bigger team gives you more time in parallel. Money buys other people’s time and experience. Better tools compress the time needed to get from an idea to an outcome.

So maybe vibe coding has not removed the time problem at all. It has just moved it.

It compresses execution time. The distance between an idea and something that works can shrink to a few hours. That means more ideas can be tried, more things can be thrown away, and more people can build without first needing a large team or a lot of money.

But it cannot give me three years of experience watching how people use a product. It cannot replace the good judgement that comes from hundreds of user interviews. It does not immediately tell me which feature will still matter two years from now, which design decision I will regret, or what should never have been built in the first place.

The first days of a new project make this easy to forget because progress is so visible. Yesterday there was nothing. Today there is a product.

Later, progress looks different. You might spend a week removing things, reworking the same flow, or realising that the feature you were excited about solves the wrong problem. The product may barely look different, but your understanding of it has changed completely.

And this brings me back to Minecraft.

As a kid, I thought my problem was that building took too long. If only I could place the blocks faster, I could finally build everything I imagined.

Now the blocks can be placed almost instantly.

And I am starting to realise that placing the blocks was never the part that took the most time.