Quick upfront note: this isn't a sales pitch. I haven't built a Lovable competitor, I'm not launching anything, and you won't see me on a yacht in Monaco this summer. What I have built is a prototype that reflects what I think is wrong with tools like Lovable — but this post is really about the bigger picture, drawn from my experience as a Flutter developer, my master's thesis on how tech startups actually scale, other studies and books I've read, and a fair amount of trial and error along the way.

It's a long read. Please don't hand it to your favourite AI for a summary.

The Divide

Open any Instagram reel where someone says "developers are dead, I coded this whole app with fifty dollars of tokens" and you'll find the comments split almost down the middle. Half are 21-year-old boys asking how to do the same thing. The other half are 32-year-old developers listing the 143 security vulnerabilities in the app being demoed.

Both sides are partly right. And both sides are missing the actual point.

The developers are right that vibe-coded apps have real problems. Research has documented serious security issues in Lovable-generated apps. The code tends to work fine for a first version, the early features come easy, but then the AI hits a wall: a feature that's too complex, a bug it can't untangle, an architectural choice that's now baked in and wrong. The files get long. Patterns get inconsistent. Scaling becomes painful.

I recently took over an app built in FlutterFlow with heavy AI assistance. The code was horrendous, a lot of bugs. The database was wide open, with the right link, anyone could read or delete every user's data. I told the client that fixing the bugs inside the existing FlutterFlow mess would take so long that the most efficient path was actually to refactor the whole thing into proper Flutter with clean architecture and fix the bugs along the way. I think this is going to be a recurring pattern for agencies: clients arriving with low-code or vibe-coded apps so tangled that not even the smartest AI can save them.

But the vibe coders have a point too. Why pay a development agency a fortune for something when you don't even know if anyone will use it? Plenty of developers are still wired for the old world, they want to build the perfectly architected, future-proof, infinitely scalable system with beautifully named endpoints, and then the app launches and eleven people use it twice.

What I think is happening, underneath the Instagram wars, is that developers feel offended because their specialisation suddenly looks less special. People take pride in their craft and tie their identity to it. When someone with no background claims twenty-five euros of tokens can replace thirteen years of experience, of course it stings.

What Both Sides Are Missing

Both camps are arguing about the wrong axis. Developers are arguing about code quality. Vibe coders are arguing about speed. Both are real concerns, but neither is what most early-stage apps actually die from. Most apps die from building something nobody wants, and you can't out-engineer or out-vibe-code that problem.

This is where I have to bring in some of the work from my master's thesis. I spent about seven months researching how tech startups actually succeed, interviewing nine founders, reading through the lean startup literature, mapping out what changes as companies scale. The consistent finding across every case was that success comes from validated learning: running fast experiments, getting real feedback, and being willing to pivot based on what the data says. Code quality matters, and so does shipping speed, but they're solving smaller problems than the one that kills most products.

Eric Ries's build-measure-learn loop is the core of this. You turn an idea into a product, measure how customers respond, learn, and decide whether to pivot or persevere. In the early stages, what you need isn't a perfectly architected system, and it isn't just raw output speed either. It's the shortest possible loop between an assumption and evidence about whether that assumption is true.

Vibe coding on Lovable shortens the build part of that loop. It doesn't touch the measure-and-learn part. And that's the part that actually decides whether the thing you're building is worth building.

What My Thesis Taught Me About This

Quick detour, because the rest of this post leans on it. My master's thesis looked at how nine tech startups evolved their lean startup methods as they scaled. Three findings from that work map almost directly onto the AI-assisted development debate.

The first is the MVP-to-MVF transition. Early-stage startups test entire business models with crude minimum viable products. As they mature, they don't stop experimenting — they shift to minimum viable features, smaller experiments inside an existing product. The founders I interviewed described this as the thing that kept them honest at scale: a structured way to keep asking "is this worth building?" even after the company looked successful from the outside. Vibe coding skips this entirely. It's all build, no test-the-feature-first.

The second is the qualitative-to-quantitative feedback shift. In the early days, founders talk to customers directly — WhatsApp, email, lunch meetings. As the company grows, that becomes impossible, so feedback gets systematic: dashboards, analytics, NPS scores. The interesting finding wasn't that the shift happened. It was that the best-performing companies kept a qualitative channel alive alongside the quantitative one. The ones that fully replaced human conversations with dashboards lost something important and usually had to course-correct later. Most AI coding tools today help you build, not measure, and certainly don't help you keep a qualitative loop open with real users.

The third is the exploration-exploitation tension. Every scaling company I studied wrestled with the same dilemma: how do you keep exploring new ideas while also maintaining the thing that already works? The companies that handled this well didn't pick a side. They built structures that allowed both — protected innovation teams, feature flags, staged rollouts, T-shirt sizing for prioritisation. Vibe coders are pure exploration with no exploitation discipline. Traditional agencies are often pure exploitation with no exploration. Both are out of balance, and the research strongly suggests neither extreme survives long-term.

These three findings aren't about AI specifically. They're about how product development actually works at scale. But they shape almost everything I think about what AI-assisted tools should do.

Why Jensen Huang Wants His Engineers Burning Tokens

Recently Jensen Huang said that if his $500K engineers aren't burning at least $250K in tokens annually, something is wrong. The obvious cynical read: Nvidia sells the GPUs, so more token usage means more revenue. Fair enough.

But I don't think that's the whole story. I think he's trying to change a culture.

Developers are in something of an existential moment right now. A skill that was treated as rare and specialised is being reframed as something a chatbot can do. Senior developers, the ones with the most invested in the old way, are often the most resistant to AI-assisted workflows. And culture flows downhill: if the seniors dismiss it, the juniors will too.

Saying "burn a quarter million in tokens" is a blunt instrument, but it's a cheap one. Much cheaper than trying to change engineering culture at a 30,000-person company through memos and all-hands. I doubt Huang literally thinks every engineer needs to spend that much. I think he's publicly giving permission, signalling that the new way of working is the expected way. Compare that to a company capping monthly AI spend at €275 per team, which quietly signals the opposite.

Will Developers Become Obsolete?

If you don't change how you work, probably, unless you're one of the maybe 5% who are deeply specialised in something narrow and hard. The other 95% have to adapt.

But adapting doesn't just mean "use AI to code faster." It can mean becoming something closer to a technical consultant. Someone who understands the business, the market, the user, and can translate between them and the code. The code part is getting cheaper. The translation part is not.

Agencies Need to Evolve Too

It's not just individual developers. App agencies need to change too.

There will always be some demand for the old model, banking apps, hospital apps, government apps, things that need to be bulletproof, bug-free, accessible, and secure. Some of my thesis participants were in gambling and healthcare, and they described the same thing: you literally can't ship an untested MVP to customers in their industries. Regulation forces a slower, more validated approach. Some agencies will specialise here and build their brand on "we make the most secure, bug-free apps" and that's a real market.

But that's a minority. Most agencies need to move in a different direction, and I think the shape of that direction is roughly this: closer to consulting, with a heavy focus on rapid prototyping, product-market fit, and growth.

I picture the client of the future as someone who knows an industry deeply, has spotted a real problem there, has a vision and some capital, and wants a partner who can turn that into a product fast. The agency takes the vision, ships an MVP maybe the same day, puts it in front of real users or a beta group, measures, iterates. Development becomes maybe half the job. The other half is lean startup work: rapid prototyping, experimentation, finding product-market fit, and then growth hacking once the app is live.

My thesis research actually bears this out. The scaling startups I interviewed didn't abandon lean startup methods as they grew, they adapted them. Teams went from full-stack generalists to specialised functions, then to cross-functional product teams. Decision-making went from founder intuition to structured frameworks like T-shirt sizing and impact-effort matrices. Feedback shifted from close qualitative relationships to systematic quantitative collection, while the best companies kept a qualitative channel alive alongside it. MVPs evolved into Minimum Viable Features, smaller, safer experiments within a mature product.

In other words: the principles stay, but the machinery around them has to get more sophisticated. Agencies that understand this, that can run this machinery for their clients, have a real future. The ones still selling "we'll build you a perfect future-proof system" to people who don't yet know if anyone wants their product are going to struggle.

So What's the Prototype?

This brings me to what I actually built. Not a Lovable killer, but an attempt at what AI-assisted product development could look like if it took the business side seriously.

The workflow is simple. You give it whatever you have, anywhere from "I want a platform for ice cream lovers where people can rate ice creams and match with others who have similar taste" to a fully specified brief with data models, design references, and links to apps whose UX you like. More context is usually better, though not always, so the first job of the tool is filtering: what's actually useful, and what's missing.

Importantly, the "what's missing" check isn't just technical. It also looks at the business side. What's the value proposition? Who are the competitors? What's the product-market fit hypothesis? What would a first experiment actually need to test? This is the part that's completely absent from most AI coding tools today, and it's the part that determines whether the thing you build is worth building at all.

Once it has enough context, it generates the scaffolding, UX and accessibility guidelines, the design system, the feature set, the serverless backend (Firebase by default), security considerations, localization, testing. It writes the code in clean architecture so a real developer can take it over later without wanting to throw their laptop out a window. It maintains knowledge files about the project so that when a new AI session starts, to add a feature or fix a bug, it can come up to speed quickly without re-reading every file.

For apps, it uses Flutter with Material 3. For websites, React with shadcn. It's opinionated, because opinions are how you keep quality consistent.

The part I'm most interested in, though, is what happens after the first version ships. This is where my thesis research actually shapes the design. Most AI coding tools, and most vibe-coded apps, never close the build-measure-learn loop. Firebase Analytics and Crashlytics feed into a simple dashboard where the founder, not the developer, can see what's happening: which features are getting used, where users drop off, what's worth doubling down on. The tool uses that data to suggest A/B tests, flag under-used features, and surface signals that it might be time to pivot. But — and this is the part the thesis research kept hammering home — quantitative data alone isn't enough. The companies that scaled best kept a qualitative channel open alongside the dashboards. So the tool also prompts founders to actually talk to users at regular intervals, with structured interview templates and a place to log what they learn. It's deliberately the unsexy half of the product. It's also the half that decides whether anything else you've built matters.

The First App Through the Pipeline

To stress-test the workflow on something real, I'm using it to build a small consumer web app of my own. I won't say too much about it yet, it's a live experiment and I'd rather not bias the early users, but the shape is this: a group of friends needs to agree on something, one person ends up doing all the planning, and everyone else mildly resents the outcome. Low stakes, high friction, very common, and surprisingly badly served by existing tools.

What's worth mentioning for this post is how the methodology is baked into the product itself. A handful of buttons in the app look like AI features, exactly the kind of thing Lovable would happily generate code for on day one. None of them actually call an LLM. They're fake doors. Tap one and a small popup appears asking "is this something you'd really want?" with a 1–5 rating. Features that pull strong scores from real users earn the right to be built. The rest get quietly removed, and the tokens that would have gone into generating them stay in my wallet.

This is the experiment-first mindset from the management literature, applied at the feature level. It's also the part vibe coders almost always skip. Building something is easy. Knowing whether it's worth building is the harder, more valuable half.

The Actual Point

AI-assisted development isn't a threat or a gimmick. It's a shift in what the work is. Writing the code is getting commoditised. Everything around the code is not: understanding users, designing experiments, reading data, deciding when to persevere and when to pivot, knowing which architectural battles are worth fighting and which aren't. Those parts are becoming more valuable, not less.

The developers raging in the comments and the kids making "developers are dead" reels are fighting over the wrong question. The interesting one isn't "can AI replace developers." It's "what does good product development look like when the code is cheap?" And the answer, I think, looks a lot more like lean startup methodology than like either camp realises.

I don't know if my prototype is the answer. It's an answer, shaped by years of writing Flutter, months of researching how startups actually scale, and too many hours of watching Instagram reels where people with no idea what they're doing tell each other they've killed an entire profession.

The yacht in Monaco will have to wait.

References

1. Superblocks. Lovable vulnerabilities. https://www.superblocks.com/blog/lovable-vulnerabilities
2. Ries, E. (2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Publishing Group.
3. Teirfolk, T. (2025). Balancing Innovation and Growth: The Evolution of Lean Startup Methods During Scaling. Master's thesis, Hanken School of Economics. https://helda.helsinki.fi/items/6923bf54-9baf-4e23-9572-04c030827052