5 Products We Built with Vibe Coding: 5 Lessons Learned
We're not here to teach you how. We're here to tell you what we built, what we messed up, and what we're still figuring out.
Why We Started Vibe Coding
Ever heard of Project 12 or Project 52? Some people challenge themselves to build 12 products in a year, or even 52. The number isn't the point. What matters is that every project, big or small — from learning a tool to developing a product — fuels growth.
We admired these makers. But beyond challenging ourselves with quantity, we wanted to break free from the client work cycle and build our own products. To decide our own product direction and control service quality.
So, I started with an engineer's biggest pain point: marketing and content creation.
I took a 12-week professional services coaching course. I learned email marketing, writing newsletters, blogging, landing pages, and using Canva. It covered everything: marketing, offer positioning, product planning, and strategies for both organic and paid traffic.
The product I worked on then was an engineer career transition coaching program. Students would find their market niche and resume strengths in 8 weeks, with weekly one-on-one coaching. In the fourth week of the course, I got my first client and my first € 1,000 in revenue.
That was my only revenue during the 12-week program. But for a beginner, I gained more than just money; I gained skills beyond coding. It opened my eyes to product positioning and personal branding. Stay hungry. Stay foolish.
My partner comes from a C++ BIOS engineering background, moving to full-stack engineering (CI/CD Infra to Smart Contract development), and now specializes in AIOps. Our skills complement each other, and we both wanted to leave client work early.
We started using AI in 2022 to speed up learning and lower barriers. By 2025-2026, AI made building things even faster. With tools like Gemini and Claude Code, you can genuinely create a usable Flutter app in half a day.
But there's a long road between building it and people actually using it.
Over the past year, we've built five products. Some are still in development, others we've shelved. Each product taught us a lesson.
CourseKit: Only Problems People Ask About Deserve a Product
CourseKit was originally built for my family.
They had over 200 beauty and language courses to track. They used LINE notes, but it was too cumbersome to cross-reference. Friends also found the tool useful, so I expanded the features and built iOS and Android cross-platform versions with Flutter, then launched it on app stores.
After launch, it received some good reviews on iOS, confirming a market need.
I realized that the demand for session management wasn't just for beauty courses. It applied to strength training and tutoring too. Coaches used notebooks, comparing times and session counts between LINE chats and notes. It was a small inconvenience that grew into a big problem over time.
For the second version, I repositioned it, targeting budget-conscious individuals and those offering professional services as a side hustle. It allowed self-tracking of learning, beauty, and exercise sessions and expenses, and supported session management and member records for side businesses.
I don't like installing single-function apps. So, I approached it with a 'less is more' mindset, thinking about what budget-conscious users and side-hustle owners truly needed.
The answer: an incredibly simple tool that lets them focus on the core service.
After launching the second version, I had pilot coaches and students test it and collected feedback. The results were a bit surprising: the scheduling feature, which I hadn't planned to build, was what users wanted most. Session management was important, but they also wanted scheduling.
This gave me a real-world lesson: the market will tell you, users will tell you, where the problem lies.
You might think you know what users want, but until the product is actually in their hands, your assumptions are just that—assumptions. Solving user problems is the true value of a product.
CourseKit is still being updated and has a small number of paying users. Each conversation with a potential user brings us closer to the right product.
It's not about getting it right the first time, but getting closer each time.
Who Is The Spy: Fun Isn't the Same as Repeat Engagement
This was a party game our partner built using Google AI Studio.
When it was done, we had a lot of fun playing it ourselves, and our friends liked it too.
But honestly, I thought the results were just okay. I wasn't sure it would attract people to play it repeatedly.
And indeed, fun and getting people to keep coming back are two different things.
Think about how many games are on your phone. You download them excitedly, play a couple of times, find them okay, and then never open them again. That's the reality for entertainment products.
The stickiness of entertainment products is completely different from utility products. Tools solve problems, so people keep using them. You won't stop using your budgeting app because you need to track expenses daily. But a game might be fun once, and next time you might want to play something else.
This doesn't mean entertainment products shouldn't be made. But if you're building one, you need to think clearly about one question: why would someone open it a second time?
Is it new levels? New characters? Social pressure? Leaderboards? Or a different experience every time you play?
If you can't answer that, you might need to rethink the product's core loop.
Easy to build, hard to retain. That's what Who Is The Spy taught us.
My Little Star: Not Every Idea Needs Immediate Coding
My Little Star is an app our partner is currently developing.
The concept is great: parents reward children for chores or agreements, fostering mutual growth. Not with material rewards, but by completing agreed-upon small tasks, building trust and understanding between parent and child.
This product is currently in the demand validation phase.
From our CourseKit experience, we know that building endless features is pointless if no one uses them. So this time, my partner decided to validate with the simplest method first.
Before writing a single line of code, ask a few questions:
- Does this problem really exist?
- Will parents really use an app for this?
- Or can it be solved with a piece of paper or a simple chart?
Watching my partner work on My Little Star, we learned something crucial: not every good idea needs immediate coding. Try it manually first, confirm it works, then consider building an app.
Sometimes a simple chart validates your idea better than a beautifully designed app.
And by doing it manually, you'll uncover many details that automation might hide. These details often determine a product's success or failure.
Escape Coach: Knowing When to Stop is Harder Than Knowing When to Start
Escape Coach was a product we were very excited about.
The concept: an exercise class management app for coaches and students. Basic features included coach scheduling, class management, and attendance tracking.
But we wanted to do more.
We designed a reward task mechanism: students attend exercise classes, complete specified tasks, then graduate to independent training. This concept was appealing because most fitness apps want you to keep paying, but we wanted the opposite — for students to eventually leave their coach and exercise independently.
We also wanted a coach leaderboard so students could find quality coaches nearby, view ratings, specializations, and course content.
Sounds great, right? We thought so too.
The problem was, many of these features overlapped too much with CourseKit. CourseKit already handled session management, scheduling, and member records. Escape Coach meant rebuilding similar things in another app, plus adding a bunch of ambitious new features.
And it was too ambitious. Every time we thought, there's still this feature to build, it felt like we were further from completion. The logic for reward tasks needed designing, the rating mechanism for the leaderboard needed figuring out, and the coach certification process needed planning. Each feature made sense individually, but all together, the product scope became too large for a small team to handle.
It took us a long time to admit this.
Eventually, we decided to shelf it.
Not just Escape Coach. We put other ideas on hold too. A community tool connecting study groups worldwide — a great concept with demand, but not the right time. Also small utility toys: quote reminders, countdowns, habit trackers. Each could be built in a few days, but each would distract us.
Saying we weren't disappointed when we shelved Escape Coach would be a lie. It's never easy to let go of something you've invested emotion in.
But looking back, it was one of the best decisions we made. It allowed us to focus our energy on CourseKit and VCH.
This was the most valuable lesson from five products: knowing when to stop is harder than knowing when to start.
Killing a project you've invested emotion into requires not technical skill, but discipline.
Vibe Code Home: Your Own Journey is Your Best Product Inspiration
After building five products, we realized something: the hardest part was never the coding.
The hardest part was everything after it was built.
How to position it? Who is your product really for? How to price it? $5 or $50? How to get people to know about it? You built something great, but only you and your mom know. How to turn a side project into a real product?
These questions kept popping up as we built each product. We hit these pitfalls ourselves and watched other builders do the same.
On r/vibecoding and Indie Hackers, we saw a recurring pattern: someone uses AI tools to build something amazing over a weekend, then posts "It's done!" and gets a ton of likes.
Then what?
Three months later, that product sits quietly on GitHub, no users, no revenue, and the creator is already on their next side project.
We don't want to be part of that pattern.
So we started Vibe Code Home.
VCH is a platform that helps vibe coders turn their creations into product assets they own. We offer positioning consulting, payment gateway integration, and marketing support, so you can focus on building the product itself, instead of spending three months figuring out Stripe setup.
Honestly: VCH is still in its seed stage.
Our projected ad revenue is 0.06 Euros. No typo, zero point zero six.
Why write this article at this stage? Because we believe sharing the real journey is more valuable than pretending to be successful already.
Too many people wait until they've made their first million to share. But by then, the sharing is filtered through memory's embellishment and survivor bias.
We choose to share now. Before we're successful. When we only have 0.06 Euros.
Because this is the real journey.
We're walking this path with you, not looking down from a mountain top.
The paths you've walked, the pitfalls you've encountered, the attempts you've made – all are assets. Organize them, and that's the most valuable thing you can give others.
Ready to Start Your Own?
You don't need to build five products to learn these lessons.
But you do need to finish at least one.
Not perfectly, but to a point where one person can use it. Then listen to what they say.
Maybe they'll tell you about a need you never considered, like CourseKit's scheduling feature. Maybe they'll say it's fun but won't use it again, like Who Is The Spy. Maybe they'll make you realize the product shouldn't have been built at all, like Escape Coach.
Either way, you'll be clearer about your direction than you were yesterday.
Five products, five lessons. If you only remember one, remember this:
Building it is just the start. The real challenge is every step after it's built.
But you don't have to walk alone.
You have to plant your own fruit, but you don't have to plant it alone.
If you're also working on a side project, feel free to check out Vibe Code Home or book a free consultation to chat about your idea.
We're still early, looking for people to walk this path with us.
