From 'I can't build this' to 'I can't stop building'
What vibe coding unlocks
The gap between idea and execution, for building websites and apps, has never been smaller.
This weekend, I ended up obsessively vibe coding an app that I think can go to market. This one I made with Claude Code, but of the 6 apps I have attempted, some of them simultaneously, four are live on my Android phone, and two I’m using regularly. Two apps are being worked on while I write this.
I have never had an easy time getting anything built for MediaNama. I can’t code, so friends have helped, and we’ve hired development shops for the build. Dev shops run multiple projects at the same time, and never commit fully to them. They often work with a mix of employees and external resources who are always stretched beyond capacity, so something always falls through the cracks.
They pareto their projects: finish the 80% scaffolding and basic functionality quickly, and then the last twenty percent gets stuck and moves at a snails pace because there are small nuanced changes that need to be made, and all the testing is on you, the buyer.
I’ve had to make a longlist of changes and fixes, and have to check for each of them again a few weeks (or a month) later. The output is usually not what you wanted, and never as fast. It’s not all their fault, because there’s scope creep, and there are things that you forgot to mention in the scope, or something changes, or you think of something new. No one is to blame.
I’ve done this a lot for MediaNama over 18 years, so I have some experience directing online products. My wife has none, but I just connected OpenAI’s Codex to Vercel for her few days ago, and she has so far launched two websites on vercel, including one for her architecture firm.
She’s now fine-tuning that with AI whenever she gets time.
When the tooling becomes invisible
I had never heard of Vercel before six months ago, when an Android app I paid for had a website hosted on it. It was probably vibe coded. I don’t know what Node.js is. I don’t know Python. I just signed up for vercel and asked Claude to connect it. After that, I just built sites I needed without thinking about that is done. A few days ago I set up chartnama.vercel.app for MediaNama’s journalists to use, in abut an hour minutes, using OpenAI’s Codex.
I have ideas. I have a product mindset. I think about user experience and I “dogfood” things: I know how something can improve when I use them.
When I wanted to build Android apps, I asked Claude to install all the tooling, and over about an hour and a half, it set up Android Studio, Gradle, Node.js, Python, and later when it was needed, Docker, WSL and Supabase. Each piece has been installed without me understanding what it was for or how it worked.
The friction was always the tooling: knowing how to code, which service to use for what, how to connect them and how to use them together. Now I don’t need to know any of it.
The constraint is no longer “Can I build this?” The number of creators is going to increase by orders of magnitude.
What vibe coding unlocks
When building was slow and expensive, the constraints sorted ideas automatically: Finding a developer, testing them, figuring out the right one, being able to afford one: these were all bottlenecks in developing your own apps before vibe coding became a thing.
Vibe coding addresses this friction to an extent, alongside reducing the time taken for a workable output that you can test, and between implementing a feature change, a fix or an upgrade.
It means that I can move from an idea to a fully functional app, despite vibe-coding rate limits, in less than 2 days.
It also means that I can have multiple machines working on multiple ideas at the same time (I’ve lost count), because I can spot new problems, be frustrated with the quality, look-and-feel, usability and feature set for another one. I wrote earlier that we’re moving from “there’s an app for that” to an “there’s an app for me”, assuming that the app economy is going to collapse because everyone will want to build an app for themselves.
The point, however, is that they’re not going to. Building something that works how you want it to work means you need to be able to identify use-cases, fixes, how something could become better, and how it could become better for you. In all this, an opportunity remains: how to make something better for everyone.
Because the tooling is largely free, the setup is automated, and the gap between knowing what you want and having something working is now a couple of hours, this changes who gets to be a builder.
I now think that the “there’s an app for that” market isn’t over yet. My “Someday” list is now a pipeline.
The number of apps and tools created is going to increase by orders of magnitude. You’re going to ship more things at once.
What still slows you down
A few challenges still remain, and need to be taken:
One, the question now is prioritisation: what do I build first. If you have a lot of ideas, like I do, and when you think of a problem, your first thought is “can I build an app for this?“, you have a sequencing problem. I have three machines working on three completely different apps/sites at the same time, one running Claude Code, another Codex. I use free Kimi K2.5 tokens from Nvidia NIM, and Minimax M2.5 on Opencode for the planning and the initial PRD.
Two, there are OS level limitations: There are things, of course, that cannot be built: I had an idea of an Undo app for the mobile, (adding a user-determined delay, so you can cancel a tap on a send button), but it’s not possible in Android’s sandboxed environment. Some apps I’ve tried require accessibility permissions, while others require system control. Not everyone will give these permissions.
Three: security. The lingering doubt I have about every app and tool that I’ve built is that, especially if there’s personal data (one has health data), how safe is it? I don’t code, I can’t test code. I don’t know if AI can test code written by AI for security. I can’t risk it crashing on someone, getting hacked, being used to hack or compromising personal data. Anything that touches sensitive data or requires audit trails still has a real moat.
Four: distraction. I have at least two great apps that require my attention, but I’m now fleshing a whole new app idea that I had set aside a week ago as just a PRD (Product Requirements Document). The key constraint is human cognitive bandwidth. You can generate too many parallel ideas and fail to ship or scale any one effectively.
Five: What do I go to market with, and how? How much do I spend? Nothing will stay unique for long, and someone will use AI to copy it.
Six: how do I price this? Since everything is commoditised, someone can copy the screenshots and build it for themselves if there’s a paywall. This means, like I wrote earlier, paywalls are dead, and people will have to pay for lifetime value in one shot. This means there’s downward pressure of lifetime usage cost, and so you’re better off building one-time purchase apps, and then charging for updates. LTV (Lifetime value) of apps shrinks because the lifetime shrinks. This means that the portfolio is the right model, not the single bet. Every time there’s an app, there’ll be ten. We need to think hard about user lock-ins.
Seven: Speed of going to market is now the competitive advantage, and how fast you can grow adoption matters, before someone copies it. The monetisation window has shrunk. Every idea you’re sitting on is already decaying. The window between having something unique and having fifty versions of it on GitHub is weeks.
What’s still defensible? Anything connecting online to offline, anything regulated, SaaS embedded deep in an organisation’s workflow, as I wrote previously. What’s changed is the urgency with which everything outside those categories has to move.
Ps.: If you’re wondering about how many vibe-coded projects I’m working on, the answer is I don’t know. I have lost count. Some are done and being used, some are done and abandoned. Some are half done, needing improvements. Some require more infra (and the cost of AI API’s). All I can say is that more than 10 projects have been begun in the last two weeks. That’s why this is an unlock.