Today, I can start building a digital product much faster than I could just a few years ago.
I describe an idea, outline its core features, open my code editor, and start building with the help of artificial intelligence. In a relatively short time, I can have a working interface, the initial application structure, and the first features that actually work.
For someone who has spent years developing websites and applications the traditional way, that's an extraordinary change.
But there's something AI tool demonstrations tend to leave out.
A first prototype is not the same as a finished product.
There's far more work between those two points than it might seem. And in my experience, that's where the most interesting part of product development begins.
The Moment an Idea Becomes Possible
In the past, every new idea came with a serious question: how much time would it take to build?
I had to think about the technology stack, database structure, user interface, application logic, and all the little complications that would emerge along the way. Of course, I still think about those things today. What's changed is how quickly I can test an assumption.
AI has allowed me to move more ideas from the thinking stage into experimentation.
That's how projects such as Fridica, ProjectFlow, and AI Website Builder have taken shape and evolved.
They're different products, aimed at different users and problems. But they have something in common: developing them has repeatedly brought me back to the question of what really happens when an idea stops being just an idea.
At first, everything feels exciting. You see the first screen, click a button, get a result, and think: this might actually work.
And then you start using your own application seriously.
The Prototype Works. But What Happens When You Actually Use It?
As I develop a product, I increasingly try to look at it from the perspective of someone who knows nothing about how it was built.
Users don't care whether I wrote a feature manually, with the help of an AI coding agent, or through a combination of tools.
They care whether it works. Whether they understand what to do. Whether they can save what they've created. Whether the application will still work tomorrow.
That's when the initial excitement quickly turns into serious work.
With AI Website Builder, for example, it's not enough for the system to generate a page that looks good the moment it appears on screen.
What happens to the images matters too. So does how projects are saved, whether files export correctly, how content management works, and what happens when someone tries something I hadn't anticipated during initial development.
Fridica raises a different set of questions.
If a tool analyzes a website and identifies an issue, how reliable is that finding? Does the user understand what needs to be fixed? Is the recommendation specific enough to support a real decision?
ProjectFlow presents another challenge. Simply displaying projects, tasks, or available opportunities isn't enough. The information needs to be useful, easy to navigate, and sufficiently up to date for someone to rely on it.
Three different products. Three different sets of challenges. One shared lesson: software doesn't become useful simply because we've managed to build it.
AI Can Write Code. But Who Decides Whether It's the Right Solution?
One of the biggest changes in how I work is that I spend less time thinking only about how to write a particular piece of code.
Instead, I spend more time thinking about what that code is supposed to achieve, how it fits into the rest of the system, and what could go wrong.
An AI coding agent can suggest an implementation. It can identify a bug, write a test, or offer several possible approaches.
But its solution isn't automatically the right one.
Sometimes I get a feature that appears to work but creates a problem somewhere else. Sometimes one case gets fixed while two existing ones break. Sometimes a proposed change makes the system unnecessarily complicated.
There are also moments when an answer sounds convincing without actually solving what I asked for.
That's why I've come to value clear specifications, small steps, tests, and checking how an application behaves in practice.
In other words, AI hasn't removed the need to understand software development.
It has changed where that understanding matters most.
The Most Expensive Mistakes Aren't Always Technical
When we talk about building digital products, it's easy to focus entirely on technology.
Which model should we use? Which programming language? Where should we host the application? How can we reduce API costs?
These are all important questions, and I deal with them regularly.
But I've gradually realized that some of the most important decisions have very little to do with code itself.
Who am I building this product for? Why would someone use it? How will they discover it? What do they actually need, and what have I added simply because it was interesting to build?
It's especially tempting to keep adding features. When development becomes faster, it's easy to feel that every new idea should immediately become a new function.
But more features don't necessarily make a better product.
Sometimes it's more useful to improve one existing feature, simplify the interface, or explain clearly what the application does.
And sometimes the most important decision is choosing not to build something.
Between a Working Product and a Sustainable Business
There's another part of this story that doesn't get discussed enough.
Building a product isn't the same as finding users. And finding users isn't the same as building a sustainable business.
You can have a working application, a good idea, and a beautifully designed website, yet still lack a clear answer to how the project will survive in the long run.
Development also involves hosting, maintenance, support, service costs, communication with users, documentation, and promotion.
All of these require time and attention.
This is a particularly important lesson for me because it's easy to fall in love with the process of creating. There's always something else I could improve, another experiment I want to try.
But if I want a digital product to become something sustainable, I have to think beyond the development environment.
AI can significantly lower the barrier to starting development. It cannot, by itself, give people a reason to keep coming back to a product.
Why I Want Us to Talk Openly About the Process
Experiences like these are part of what inspired the IT Komuna I want us to build.
Not another place where we only showcase finished products or announce the latest release of a tool.
I'd like us to talk about everything that happens between the initial idea and the final result.
The problems we didn't have ready-made solutions for. The technologies we chose and later reconsidered. The things that worked, and those that didn't.
I believe these stories can be more useful than another list of the best AI tools.
Because someone thinking about building their first application might need more than advice on which tool to open.
They might need to understand how to validate an idea, organize development, decide what to test, and recognize when it's time to stop adding features.
And perhaps what matters most is realizing that products which look simple from the outside often involve countless attempts, revisions, and lessons along the way.
Learning Through Real Products
That thinking also shapes the concept of AI Product Lab within IT Komuna.
The idea is simple: what if we learned by developing real digital products together?
Not just through lectures and tutorials, but through concrete tasks, conversations, collaborative problem-solving, and testing what we've built.
Programming would be one part of that process, but not the only one.
There would also be room for design, user research, project management, content creation, testing, analytics, and communication.
This approach could bring together people with different experiences and interests.
For now, AI Product Lab is a direction we want to develop, not a finished program with promised outcomes.
But I believe the idea makes sense precisely because it grows out of what I've learned while working on my own products: we understand things most deeply when we try to build something, encounter a real problem, and figure out how to solve it.
The First Prototype Is Only the Beginning
I still enjoy the moment when a new idea first appears on screen.
When something that was just a sketch or a note yesterday becomes an application I can open, test, and show to others.
AI has made that moment far more accessible.
But I see it differently now.
It's no longer the moment when I think most of the work is done.
It's the moment when I can finally start seriously testing whether my idea makes sense.
And that's where the part of product development I find most rewarding begins: experimenting, learning, improving, and trying to turn something that works into something people genuinely find useful.
Because writing code may be easier than ever. Building a good product still takes a great deal of thought.
And perhaps that's exactly why this is such an exciting time to learn and create together.