From Zero to One: Building My First Web App with AI

A week of mistakes, breakthroughs, and hard-learned lessons in the AI-assisted development of a tool to help Google Ads marketers

Daniel thinking about how to build this friggin app.

As someone with absolutely zero development experience, I decided to do something that probably seemed crazy to anyone watching: build a web application from scratch using Claude AI as my coding partner. The goal? Create a tool that helps Google Ads marketers and business owners refine their targeting.

What started as a simple experiment quickly became a rollercoaster of wins, epic failures, and valuable lessons. I decided to document this journey transparently – not just the successes, but especially the mistakes and vibe coding challenges that nearly derailed the entire project.

The Original Vision

The concept was straightforward: build a tool that could analyze Google Ads data and provide intelligent recommendations for improving campaign targeting. Nothing revolutionary, but something that could genuinely help marketers make better decisions with their ad spend.

Y'all know me. I love my negative keywords and Google guardrails.

Within the first few days, I had something working. A simple, single-page web application that could process thousands of data points and generate useful insights. I was thrilled – this AI-assisted development thing actually worked!

That's when I made my first big mistake.

Problem #1: The "Perfect is the Enemy of Good" Trap

Here's what happened: I had a working tool that successfully processed over 31,000 data points. It wasn't pretty, but it worked. The analysis was solid, the recommendations were helpful, and early testers (me) were giving positive feedback.

But it felt too simple. Too "amateur."

I convinced myself that a "real" web application needed a proper backend, a database, user authentication, and all the bells and whistles that come with modern web development. So I asked Claude to help me convert my simple, working client-side app into a full-stack application.

This decision nearly killed the project.

What I learned: Sometimes the "quick and dirty" solution actually IS the right solution. Your users care about solving their problem, not admiring your technical architecture. Ship the MVP first, then iterate based on real user feedback.

Problem #2: When AI Debugging Goes Wrong

Here's what happened: This was perhaps the most frustrating issue of the entire week. As we worked to convert the simple app into a complex one, bugs started appearing everywhere. Claude would identify an error, suggest a fix, and I'd implement it. But instead of solving the problem, each fix seemed to create two new issues.

It took me days to realize what was happening: Claude was consistently misreading line numbers in the code and applying fixes to the wrong lines. When it said "change line 47," the actual problem was on line 23. Every "fix" was breaking working code.

The cascading errors were incredible. Duplicate declarations, Router errors, context issues – each debugging session made things worse. I felt like I was trapped in a nightmare where every solution created new problems.

The breakthrough came when I stepped back and asked a simple question: "What if we've been fixing the wrong things this entire time?"

What I learned: When debugging spirals out of control, don't keep pushing forward. Step back, start fresh, and question your assumptions. Sometimes the tool (even an AI tool) can be the source of the problem.

Problem #3: Over-Engineering Everything

Here's what happened: Once I realized my working single HTML file was actually broken by trying to make it "professional," I faced a choice: continue fighting with the complex version or go back to what worked.

My developer friends would probably laugh, but I had fallen into the trap of thinking that a single HTML file wasn't "real" development. It felt amateur. Surely a proper web application needed:

• A separate frontend and backend

• A database

• User authentication

• API endpoints

• Proper routing

• Error handling middleware

• AI integrations

The reality? My single HTML file was actually a perfectly professional deployment strategy. It:

• Processed data entirely client-side (eliminating server costs)

• Scaled infinitely (every user's browser did the work)

• Deployed instantly to GitHub Pages (free hosting)

• Had zero dependencies or failure points

What I learned: Complexity should be added only when users actually need it. Start with the simplest solution that works, then add features based on real user demands, not imagined requirements.

Problem #4: Real-World Data is Messy

Here's what happened: One technical challenge that caught me completely off-guard: data parsing. My tool needed to process CSV files exported from Google Ads, and I naively assumed this would be straightforward.

It wasn't.

Marketing data is incredibly messy. App names like "Mobile App: Easy Math, AI Helper" and "Business Tool: Analytics, Reporting & More" contain commas, quotes, and special characters that break standard CSV parsing. What should have been simple comma-separated values turned into a parsing nightmare.

The solution was surprisingly simple: use pipe separators (|) instead of commas for data export. This handled all the edge cases without complex escaping logic.

What I learned: Real-world data is always messier than you expect. Build robust parsing from the start, and always test with actual user data, not clean sample files.

Problem #5: Version Control Assumptions

Here's what happened: This might be the most embarrassing mistake of all. As a non-developer, I set up a Git repository thinking all my files would automatically be backed up. I made this assumption and never verified it.

When the complex version broke everything and I needed to go back to the working version, I discovered my Git repository was empty. All my "backups" existed only in my head.

I had to reconstruct the working code from our conversation history – essentially reverse-engineering my own application from chat logs.

What I learned: Set up proper version control BEFORE making any changes. Verify it's actually working. Make your first commit with your working code, then start experimenting.

The Wins That Made It Worth It

Despite all these problems, the project succeeded. Here's what I ended up with:

Technical Wins:

• A working web application that analyzes thousands of marketing data points

• Professional UI with detailed recommendations

• Zero server costs with GitHub Pages hosting

• Proper data handling for complex CSV structures

• Ready for user testing with real marketers

Process Wins:

• Client-side processing eliminates ongoing server costs

• Single HTML file deployment is actually professional and reliable

• Rule-based logic often works better than AI for predictable analysis tasks

• Progressive enhancement is a viable development strategy

Business Wins:

• Live deployment ready for user testing

• Real problem solved for Google Ads marketers

• Perfect lead magnet for digital marketing services

• Proof that non-developers can build useful tools

What's Next?

The current version uses rule-based logic for analysis, but the next phase involves adding a hybrid AI system for edge cases. The goal is to combine the reliability of rules with the intelligence of AI for uncertain scenarios.

More importantly, I'm now focused on getting this tool in front of real users to gather feedback before adding any new features.

Key Takeaways for Aspiring Builder-Entrepreneurs

1. Ship first, polish later. Your working MVP is infinitely more valuable than your perfect app that doesn't exist.

2. Question your tools. Even AI assistants can lead you astray. When things aren't working, step back and verify your assumptions.

3. Embrace simplicity. Complex solutions aren't automatically better. Often, the simple approach is more reliable, cheaper, and easier to maintain.

4. Real data is messy. Always test with actual user data, not clean examples.

5. Version control is non-negotiable. Set it up first, verify it works, then start building.

6. Users care about problems solved, not technical architecture. Focus on delivering value, not impressing other developers.

The Bottom Line

Building this application taught me that AI-assisted development is incredibly powerful for non-developers, but it's not magic. You still need to think critically, make good decisions, and focus on solving real problems.

The most important lesson? Sometimes the "amateur" solution really is the professional one. Don't let perfect be the enemy of good – or in my case, don't let complex be the enemy of simple.

What's been your biggest development mistake that turned into a valuable lesson? I'd love to hear about your journey in the comments.

Want to follow along as I continue building and testing this tool? Connect with me on LinkedIn for regular updates on this AI-assisted development experiment.