Software used to be written. Now it is described.
A few years ago, that sentence would have sounded strange. Today, it is starting to feel obvious. AI did not just make coding faster. It changed the cost of turning an idea into a working product. And when the cost changes, the whole logic of building products changes with it.
For years, I had ideas for apps. Many people do. You sit in a meeting, hear the same problem again, and think, someone should build something for this. Then real life continues, because building software was never as simple as having the idea. It meant developers, time, budget, documents, testing, servers, and more patience than most people have after a full working day.
At the center of that world was the MVP, the Minimum Viable Product. I understand why it existed. Software was expensive, so the smart thing was to build the smallest version possible and test if people cared. In theory, that is very rational. In practice, for someone like me, it often meant spending months and real money to build the weakest public version of your own idea, then showing it to people and hoping they understood the vision behind the missing pieces.
They called it validation. I always felt it was a very expensive way to be embarrassed in public.
Let me give some context. I am a Computer Engineer, at least on paper. I studied Fortran, C++, and Java. I got a B in Java, if you are wondering. After that, the software industry and I quietly agreed to go in different directions. The market looked at my engineering degree and decided I was better in business. To be fair, the market was right.
I was good at explaining things. I was good at taking something complicated and making people understand why it mattered. That skill carried me through business development, product work, leadership, government work, and advisory roles. I stayed close to technology for many years, but not as the person writing the code. I was usually the person asking for the product, explaining the need, and pushing the team to make it useful.
That is why building software always felt both close and far. I could see the problem. I could describe the user. I could write the business case. I could explain the flow. But the actual building part needed a team, a budget, and a long tunnel. So, like many people, I parked ideas under “someday.”
When I left my career and started my own business, I went in a very classic direction. Real estate development. Fire and life safety engineering. Things with clear demand. Things you can touch. Land, buildings, codes, inspections, real customers, real problems. It was honest work, and it made sense. No one asked me about burn rate. No one asked about user retention. The demand was already there.
But while I was busy with land, buildings, and fire codes, something changed quietly in the background. The cost of building software started to fall, not a little, but a lot. I discovered it through one of the most boring problems in my daily life: SMS.
For years, I was the SMS department of my family and my business. My wife has a supplementary card under my credit card, so her card notifications come to my phone. Every purchase, every alert, every time. Naturally, she needed those messages too. So I used SMS forwarding apps.
Then business added more cases. Some messages needed to go to the accountant. Some to the lawyer. Some to a project manager. Some to a family member. Some to me, but also to someone else. The problem was simple: the message arrives on one phone, but the person who needs it is somewhere else.
I tried several SMS forwarding apps. Some worked for a while. Some were full of ads. Some asked me to subscribe before I could understand what the app actually did. Some had old interfaces. Some depended on servers. Some could not handle sender IDs well. And most of them felt like they were built by someone who understood code, but not the daily mess of business and family life.
I did not want something complicated. I wanted three things: easy, private, and reliable. Easy because I did not want to spend an hour setting up a simple rule. Private because SMS messages can include banks, codes, government notices, and personal information. Reliable because a forwarded message that arrives late can be worse than no app at all.
The old version of me would have added this idea to the “someday” list. This time, I did something different. I opened an AI coding tool and described the product the way I would brief a contractor. I explained the problem, the user, the flow, and the things I refused to accept.
No servers. No account. No data collection. Filtering and processing on the device. Simple rules. Clear logs. Android first, because Android allows the SMS permissions needed for this type of app.
A few evenings later, it was no longer just an idea. It became Forwardit, a private SMS forwarder for Android. It is now in closed testing before launching on Google Play. Built by a man whose last serious coding achievement was a B in Java. Let the record show that the B is finally doing some work.
This is why I started Muhab Labs. Do not imagine a big office. There is no lab coat, no glass room, and no large engineering team. Muhab Labs is a PC, coffee, and late nights. It is me taking small problems I understand very well and trying to turn them into real products.
The strange part is not that AI helped me write code. The strange part is that I no longer feel blocked by code.
That is the real change.
For years, the main question was, can this be built? Today, for many products, that question is becoming less important. Of course it can be built. The harder questions are different now. Is the problem real? Do people care enough? Is the product simple enough? Can you explain it in one sentence? Can you say no to features? Can you make it trustworthy? Do you understand the user better than someone who is just copying the category?
This is why I think the M in MVP is dead.
The “minimum” was never really a philosophy. It was accounting. Software was expensive, so we had to build the smallest thing possible. Change was expensive, so we created methods to manage the pain of change. Testing was expensive, so we tried to validate before building too much. That made sense at the time.
But when AI makes the first working version much cheaper, the meaning changes. Why build the weakest version of your idea if you can build a decent one in almost the same time? Why test a slide when you can test a working product? Why spend weeks arguing about a mockup when people can actually use the thing?
I am not saying MVP was wrong. I am saying the reason behind it has changed.
The new product is not always a Minimum Viable Product. Sometimes it is an AI Viable Product. Not a product about AI, but a product that exists because AI changed the cost of building it.
And code is only one part of the story. Around every product there is another product, the company around it. Market research, positioning, brand, website, SEO, privacy policy, tutorials, launch plan, translations, support. These things used to slow people down too. Not because founders did not care, but because every part needed time, people, and budget.
Now many of these parts can start at the same time as the product. Not perfectly, but well enough to move. That is a big deal. It means small builders can act like real companies much earlier. It means people who understand a problem deeply can try to solve it without waiting for permission, a big budget, or the perfect technical team.
But this does not make building easy. It makes excuses harder.
When building becomes faster, judgment matters more. Taste matters more. Clarity matters more. Understanding the user matters more. Knowing what not to build matters more. AI can help you build faster, but it will not tell you which problem is worth your life. That part is still on you.
Forwardit is a small product. It will not change the world. It simply solves a problem I had for years. But for me, it proves something bigger. The tunnel is shorter now. The old excuse is weaker now. The “someday” folder is less convincing now.
If you have a problem you understand deeply, and you have been waiting for the right team, the right budget, the right developer, or the right moment, maybe the moment has changed. Maybe the thing you were afraid of no longer costs years. Maybe it costs evenings.
This page is called Thoughts, and that is what this is. My thought is simple: the M in MVP is dead.
The minimum is not the point anymore. The point is judgment. The point is clarity. The point is building something useful enough for real people to care.
So if you have an idea you keep burying under “someday,” maybe it is time to open it again.
The excuse you were using has been discontinued.
Go build it.