2.5 Years of Vibe-Coding — What I’ve Learned

A retrospective on building seven production apps without knowing how to code — the wins, the failures, and the honest truth

Two and a half years. Seven production applications. Zero formal coding education. One very patient AI.

When I started this journey — a 48-year-old product executive picking up Retool for the first time — I had no roadmap. No mentor. No plan beyond „I wonder if I can build this thing.“ Now, looking back from the other side, I want to share what I actually learned. Not the highlight reel. The real thing.

The Portfolio: What I Built

Let me lay it all out:

1. Internal dashboards (Retool) — Where it started. Simple, ugly, functional.

2. VIES API — EU VAT validation. First public-facing tool.

3. Micro-Cap Trading System — Ambitious. Educational. Unprofitable.

4. Business Konzept Generator — AI building AI tools. Meta.

5. Maritime Logbuch — Digital ship’s log. The seed for Marina Master.

6. Schiersteiner Wochenmarkt — Community platform for our farmers‘ market.

7. CalendarGenie — Screenshot to calendar events. Simple, beloved.

8. Post-er — AI content creation with 5 providers, video, credits, PWA.

9. Energy Backbone — IoT SaaS with smart meters, Raspberry Pi gateways, prepaid billing.

10. Marina Master — 35+ feature marina management system with AI contracts and WhatsApp.

11. Paperless-ngx RAG — Semantic search and AI chat for document management.

That’s eleven projects, seven of which are in active production use. Built by one person. In evenings and weekends. While holding a demanding full-time job as Executive Director at CRIF.

I’m not saying this to brag. I’m saying it because two and a half years ago, I would have found this list completely unbelievable. And I think you should find it believable — because the tools that made this possible are available to everyone.

What Actually Worked

1. Domain expertise beats coding skill

This is the biggest lesson. My 25 years in business, product management, and enterprise technology didn’t become irrelevant when I started coding — they became more valuable.

I knew what marina operators needed because I live in a marina. I understood payment systems because I worked in financial services. I could design a multi-tenant architecture not because I’d studied computer science, but because I’d managed multi-tenant business operations for a decade at Bertelsmann.

The code is the easy part. Knowing what to build — that’s the hard part. And that’s where non-developers have an unfair advantage.

2. Ship early, iterate fast

Every successful project followed the same pattern: build the minimum thing that solves the core problem, get it in front of users, iterate based on their feedback. Every failed experiment happened when I planned too much and built too long before showing anyone.

The trading system? I spent weeks on architecture before testing the core hypothesis. If I’d started with a simple script that tracked Reddit sentiment for two weeks, I would have saved myself a month of wasted effort.

3. The conversation is the product

Vibe-coding isn’t about prompts. It’s about conversation. The quality of what I build is directly proportional to the quality of my dialogue with Claude. Vague descriptions produce vague code. Precise, contextual, product-oriented descriptions produce excellent code.

Over time, I’ve developed a „language“ for talking to AI about code. I describe features in user stories. I explain the why, not just the what. I share architectural context. I ask for trade-off analysis before making decisions.

This is a skill. It can be learned. And I think it will become one of the most valuable skills in the next decade.

4. CLAUDE.md changes everything

Putting a structured project guide in every repository — explaining the architecture, conventions, and gotchas to the AI — was the single most impactful productivity improvement I made. It turned every Claude Code session from „let me re-explain everything“ to „you already know this project, let’s build.“

If you take one tactical lesson from this series, make it this one.

5. Solve your own problems first

CalendarGenie exists because I was frustrated. Energy Backbone exists because my marina does electricity badly. The Wochenmarkt app exists because our volunteer organization needed it. Marina Master exists because I keep a boat.

Every good product started with my own frustration. The projects I built for hypothetical users (the trading system, some early experiments) went nowhere.

What Didn’t Work

1. I underestimated maintenance

Building is fun. Maintaining is work. Every one of my applications needs ongoing attention — dependency updates, API changes, bug fixes, user support. Eleven projects is a lot for one person to maintain.

I’ve learned to be more selective. Not every idea deserves to become a product. Some should stay experiments. Some should be abandoned. The excitement of „I can build this!“ needs to be tempered by „should I maintain this?“

2. Technical debt is real and sneaky

When Claude Code generates a quick solution and it works, the temptation is to move on. But those quick solutions accumulate. Inconsistent error handling across modules. Slightly different patterns for the same operation. Configuration that should be centralized but isn’t.

In Marina Master, I’ve spent entire weekends just refactoring — not adding features, just cleaning up. That’s time I didn’t budget for, and it’s time that doesn’t feel productive even though it absolutely is.

3. I can’t debug without AI

This is my most uncomfortable admission. If Claude is down, I’m significantly less effective. I can read code well enough to understand what it does. But tracking down a subtle bug across multiple files and services? I need help.

I’m working on this. I read more code now than I did a year ago. I ask Claude to explain its decisions more often. But I’m not going to pretend I’m becoming a developer. I’m a product person who uses AI to build. And that means I’m dependent on the AI.

4. Not every problem needs an app

Early in my journey, I was so excited about building that everything looked like a nail. Someone mentions a problem? I’ll build an app for it! Except half those problems were better solved with a spreadsheet, a process change, or a conversation.

The discipline to not build something is just as important as the ability to build it.

What I’d Tell Someone Starting Today

If you’re a non-developer thinking about building software with AI, here’s my honest advice:

Start with a real problem. Not a business idea. Not a startup concept. A problem you personally have, right now, that annoys you. Build the solution. If it works for you, show it to others. If it works for others, you might have a product.

Use Claude Code. I know there are other options. GitHub Copilot, Cursor, Windsurf. I’ve tried some of them. Claude Code’s conversational approach fits the non-developer mind better than any IDE-integrated tool. You’re not editing code with AI assistance — you’re describing what you want and having it built.

Write a CLAUDE.md. First thing. Before you write a single feature. Describe your project, your tech stack, your conventions. Future you will thank present you.

Ship ugly. Your first version will be embarrassing. Ship it anyway. The feedback you get from real users is worth more than a month of polishing.

Budget for maintenance. Whatever time you think you’ll spend building, budget the same again for maintaining. If you’re not willing to maintain it, don’t build it.

Know your limits. You can build amazing things with AI assistance. You cannot build everything. Security-critical infrastructure, performance-critical systems, safety-critical applications — these need professional engineers. Vibe-coding is powerful, but it’s not omnipotent.

Don’t apologize for how you build. Some developers will dismiss what you do. „That’s not real coding.“ „Your code is probably terrible.“ Maybe it is. But it works, it’s in production, and real people use it. The end user doesn’t care about your commit history.

What The Experts Are Saying

It’s validating to hear that my self-taught lessons align with what professionals are observing at scale.

Julia Kordick from Microsoft, who introduces coding agents to enterprise customers as a Global Black Belt, told [programmier.bar](https://www.programmier.bar/podcast/deep-dive-200-coding-agents-mit-julia-kordick) something that perfectly captures my experience: „It can’t replace a software developer, but it can make a good software developer much faster.“ I’d add: it can also make a product person into a builder — which is something the industry hasn’t fully grasped yet.

She describes the 20€/month Copilot license debate with an eye-roll-inducing clarity: companies will argue for weeks about whether to buy an AI tool for their developers who cost 100k+ per year. „Even if it only makes them 5% happier in their daily work, the 20€ have already paid for themselves.“

Her take on the future is thought-provoking: we’re on a plateau right now. Single agents that work in parallel but don’t truly collaborate. The next leap will be agents orchestrating agents — tackling larger, more complex tasks. But the fundamental question remains: how do we turn juniors into seniors when the „learning through pain“ path is disappearing?

Gene Kim’s new book „Vibe Coding“ (recommended in the same podcast) tackles exactly this: not which tools to use, but the mindset, architecture principles, and workflows that make AI-assisted development sustainable. The tools have a short shelf life. The principles don’t.

And Andrej Karpathy, who [coined „vibe coding“](https://x.com/karpathy/status/1886192184808149383) in February 2025, recently described a „phase shift“ where we’re moving from AI as autocomplete to AI as collaborator. Scientific American even ran a piece titled [„How Claude Code is bringing vibe coding to everyone“](https://www.scientificamerican.com/article/how-claude-code-is-bringing-vibe-coding-to-everyone/) — mainstream recognition that what I’ve been doing in my living room is becoming a movement.

The Bigger Picture

I started this series by talking about vibe-coding as something bigger than one person’s hobby. Let me end there too.

We’re at the beginning of a fundamental shift in who can build software. For fifty years, software creation has been gatekept by formal education, years of practice, and a specific type of technical aptitude. AI is dissolving that gate.

This doesn’t mean everyone will become a developer. Most people won’t want to. But the people who have problems and the vision to solve them — product managers, domain experts, entrepreneurs, community organizers, marina operators, Marktmeister — they can now build. Not perfectly. Not the way engineers would. But functionally, usefully, and fast.

I’m one of the early ones. There will be millions more. And the software landscape will be richer for it.

Two and a half years ago, I was an insurance clerk turned product executive who’d never written a line of code. Today I maintain seven production applications, run a smart energy SaaS, and manage marinas with AI.

The tools made this possible. The frustration made it inevitable. And the journey made it worthwhile.

This was Part 7 — the final installment of „From Low-Code to Vibe-Coding.“ Thanks for reading. If you’re a non-developer who’s thinking about building, I hope this series gave you permission to start. And if you’re a developer reading this, I hope it gave you a new perspective on what’s coming.

The full portfolio:

• 🧞 [CalendarGenie](https://calendargenie.replit.app) — Turn any screenshot into calendar events
• ✍️ [Post-er](https://post-er.replit.app) — AI-powered content creation
• ⚡ [Energy Backbone](https://energy-backbone.bigdataheaven-software.de) — Smart energy management with IoT
• ⚓ [Marina Master](https://marina-master.bigdataheaven-software.de) — AI-powered marina management
• 🥬 [Schiersteiner Wochenmarkt](https://schiersteinerwochenmarkt.de) — Community market platform