📱

Get Our Mobile App

Take your business learning on the go!

Download on the App StoreGet it on Google Play

Is Your AI-Built App a House of Cards?

Hak15:09

Transcription

I was recently hired to audit an app built entirely on Lovable. Quite a niche platform in the logistics industry with very specific business logic.

Now, the founder was very excited about what she accomplished in just over 4 weeks, and I have to say it was quite impressive, at least from a feature perspective. This is a real product with early paying customers and real transactions, plus a handful of third-party APIs integrated, all built by a non-technical founder with a combination of Lovable and Cursor. The interface looked clean, the onboarding was pretty smooth, and the features they all seemed to work well, but what I found was a product built as a house of cards.

Unfortunately, this is a huge warning for every founder, especially non-technical and VI coders who think AI is some kind of magic bullet. There's a reason we're seeing shocking numbers of companies quietly ditching their AI projects because of many unforeseen risks. This is one of the stories of why.

In this video, we're going to deconstruct this house of cards. I'll show you the structural rot that AI can create when it's left unchecked. The hidden costs that the AI tool vendors will never tell you about, and I'll give you steps to keep your product from collapsing under a bigger load.

Hey, I'm Hack. I've been writing code since I was 13. Now I take 20 years of experience building software, and I combine it with a new way of making it. I build with AI every day, and I document what works, what doesn't, and what's coming next. Subscribe if you're building too.

Now, here's the thing. The founder who built this isn't done. She may be non-technical, but she's sharp, she's resourceful, and she has a lot of domain expertise. Therefore, she identified a real problem, built a real solution, and got paying customers. All without writing a single line of code herself and all in a few weeks. That's incredible. And this is the new norm.

A few years ago, this was not possible. The biggest roadblock was always the tech. But the AI coding tools made this all possible. Lovable, Bolt, Cursor, Replit, Claude Code. All these tools've turned "I have an idea" into "I have a product" in weeks instead of months. The barrier of building software has never been lower. And all of a sudden, you're not just a founder anymore. You're a builder moving at light speed, launching real businesses in days, all by yourself.

But there's a honeymoon phase with AI development, and it's intoxicating. I know this firsthand. There's a great dopamine rush every time you prompt your idea, and your coding agent brings it to life just a few minutes later. And in this honeymoon phase, everything works fine. Users are happy, and features keep shipping and piling up. The AI builds whatever you ask for, and you feel unstoppable.

But then things start breaking, and not small things, structural things. Then you realize you've been building floors on a foundation nobody ever inspected. And this is not because you were careless. No, that's not the case. It's because the tool that built it never once said, "Hey, are you sure about this?"

Now, she hired me for regular check-ins, audits, code reviews, and overall guidance on how to build better. We kicked off the initial audit, and at first glance, things looked pretty good. Clean UI and features that worked like she said they did, on the surface, at least. But then I went through the code base, the logs, and the entire plumbing.

The first thing that stood out was one huge file over 7,000 lines of code. And this was serving one of the main user flows. And it wasn't an isolated case. There were many more files like that, but this was the largest one. In software engineering, we have a name for this. They're called gut files. Every piece of logic for an entire feature, like UI, business rules, database queries, and payment handling, all tangled into one massive knot.

To a non-technical founder, this means nothing. The app works. Who cares? But to an engineer, this is a 3:00 a.m. production disaster bound to happen. Here's why you should care. Imagine your house had all its plumbing, electrical wiring, and structural beams twisted into a single ball in your living room. And now you need to fix one leaky pipe. You can't touch it without risking the wiring. And you can't touch the wiring without risking the roof. That's a god file. One bug fix in the payment logic could accidentally break user login. And AI tools will happily keep adding lines to that file, 10,000, 15,000, they don't care unless instructed otherwise.

Then I checked the back end. She was running Superbase Edge Functions, which Lovable uses as their back end in cloud option. I opened the logs and they were mostly empty. A complete black box, no monitoring, no visibility. She had no idea if functions were failing silently, how often they ran, or what they cost. A spike in users could mean a spike in hidden failures and costs, and she'd only find out when the app went down, or a shocking bill showed up at the end of the month.

Next, the API calls. Like I said, the app has industry-specific business logic and a handful of carrier APIs integrated. But there were so many redundant API calls invoked that they simply made no sense. Many text fields that would call third-party APIs on each character change. And this is a very easy-to-avoid scenario through a simple mechanism called debounce. But the AI didn't ask questions or push back like, "Hey, do you want me to put a debounce mechanism on your text fields?" And all these redundant API calls invoke unnecessary Lovable, Superbase, or Remove Versel edge functions that could turn into huge bills at the end of the month.

But the scariest part was what wasn't there. There was no rate limiting, meaning a single bad actor could flood the app with requests and knock it offline. There was no retry logic, meaning if a payment call failed because of a temporary network blip, that customer's money was just gone. There was no real error handling. One temporary outage from a vendor and the entire app crashes. This is a ticking time bomb for AI-generated code.

Recent security analysis are brutal. One study found that 45% of AI-generated code had critical security vulnerabilities. It's now estimated that one in five security breaches can be traced back to code that a machine wrote and a human didn't check carefully enough. This app was a textbook example of these risks. It was a fragile, insecure, unscalable system that seemed to work, but waiting for one thing to go wrong.

Every one of these problems has the same root cause. AI coding tools don't push back. They don't ask clarifying questions. They don't say this approach will create problems at scale, or you should split this into smaller files, or this is a security risk. Not if you don't ask it specifically. No, they just build whatever you ask it, however you ask it, and they make it look good. It's the ultimate yes man. A junior engineer would ask questions. A senior engineer would push back and explain the disastrous consequences. An AI agent will just do it. It pleases. It ships and moves on.

And if you've never worked with engineers, if you've never seen how software is traditionally built or used to be built, you don't know what to ask for. You don't know what to watch out for. You don't know where to push back because nobody in this new loop is pushing back on you. This is the gap I see. Not between technical and non-technical people, but between building and understanding what you've built.

AI doesn't eliminate your costs. It shifts them. You save time writing the first draft of the code, but then you get to pay it back sometimes with interest in debugging, maintenance, and rewrites. And the interest rate isn't linear. It's exponential. Because every file you don't understand makes the next problem harder. The context you're missing connects to other contexts you're missing. The holes link up. For those unmanaged AI code bases, the maintenance cost can be significantly higher than with traditional development if not done correctly.

Now, back to our founder. She wasn't doing anything wrong. She was building exactly the way these tools encourage you to build. Fast, iterative feature after feature. The AI said yes to everything. Nobody said wait. That's the real product of AI coding tools. Besides the code, you get confidence without comprehension.

So what's the answer? Should non-technical founders just give up on code? No, absolutely not. This is one of the most powerful tools ever created for entrepreneurs, and it's the best time to build things. What you're doing is real, and it works. But you have to protect what you've built and learn to use it like a professional, not like a hobbyist. You need to build your house on bedrock, not on sand.

Now, here are five things you can do to make this better.

1. **Use AI for prototypes, not production.** Use AI to do exactly what it's best at. Build drafts, the first versions, the MVPs. Build fast, validate, get feedback, sign those first customers. But you have to be honest with yourself that what you've built is a prototype, not a scalable product. The goal of the first draft is to earn you the right and the money to build the real thing properly.

2. **Learn the vocabulary, not the code.** You don't need to become an engineer, but you need to learn the language of software. You have to understand what an API is, what a database does, what rate limiting and monitoring actually mean. Learn what a god file is. How to work with modules and modularity. Learn what edge function costs look like at scale. Learn what dependency means. This vocabulary is what allows you to ask the AI the right questions. 10 hours of learning the concepts saves you 10,000 in rewrites later. Actually, put something together for this. It's a free tech pocket book for non-tech founders. A glossary of the most important terms in software development, explaining plain language, not in jargon. The stuff I wish someone had handed her before we started. Links in the description.

3. **Get an audit before you scale, not after.** Pay an experienced engineer for a few hours in your codebase, not to rebuild it, just to tell you where the load-bearing walls are and which ones are made of paper. A few hundred for a basic audit is the cheapest insurance you'll ever buy for your product. And if you want a starting point before hiring someone, we're building Argus. It runs automated audits on AI-built code bases, security, architecture, cost risk, and dependencies. All that jeez. It catches a lot of what I found in this video. Links in the description.

4. **Learn to prompt like an engineer.** Don't just tell the AI "Build me a billing page" or "Integrate me the payment system." You need to be the critical thinker that the AI isn't. Ask it for the trade-offs. After every major feature, ask it: What are the security implications of this? What happens if this endpoint gets hit a thousand times per second? Is this file getting too large? Should we split it? The AI will actually answer these questions well, but it won't voluntarily do it. You have to ask it first.

5. **Set up monitoring from day one.** You need to see what your app is doing. Error rates, response times, function evocations, cost dashboards. If you can't see it, you can't fix it. And you won't know it's breaking until a customer tells you.

And here's the bigger picture. The future isn't AI or humans. It's AI plus humans. Use AI to generate 80% of the code, the boilerplate, the first draft, the MVP, then bring in human expertise to architect it correctly, secure it, and build the last 20% on a solid foundation. This hybrid approach gives you the speed of AI combined with the wisdom of human experience. Because every shortcut the AI makes is a Jenga block pulled from the base and stacked on top, and the tower still stands. It even looks taller. But the ratio of weight to foundation gets worse with every feature. You don't need an earthquake. You just need one bad Tuesday.

Building a company is hard enough without having your own technology working against you. If you're a founder trying to navigate this new world and you want to keep getting deep dives on how to build sustainable, scalable tech and product with AI, make sure you subscribe to the channel.

Now, AI tools promise founders a shortcut. This is not an anti-coding video. On the contrary, I use these tools every day and can't imagine going back. But they're secopantic by nature. They're the most agreeable collaborator you'll ever work with. And sometimes what you need is not an agreement. It's someone who says, "Hold on. Let's think about this."

Now, back to our founder. She's going to be fine. The product is real and has traction, which is probably the most important part of this story. The problems are fixable. They just need to be found first, prioritized, and addressed quickly before [ __ ] hits the fan. But the pattern I'm seeing is bigger than one engagement. It's a new generation of founders building real businesses on architecture that nobody's stress testing. And the goal isn't just to build faster, it's to build smarter. The AI won't flag what it doesn't know to flag. That part's still on you.

Thanks for watching. I'm Hak. See you in the next one. Cheers.