My Biggest Takeaway from Building a Product with Vibe Coding Wasn't Technical Skill
Building an app from scratch to launch with Vibe Coding took me 3 months. Looking back, what truly changed me wasn't a technical breakthrough, but a deeper understanding of "building products." These 6 insights apply to anyone who wants to turn an idea into a product.
Intro: Why I Decided to Build My Own Product
Last year, I saw many engineers get laid off after building AI tools for their companies.
It made me think: If engineers are just turning other people's ideas into code, how is that different from contract manufacturing?
I didn't want to wait to be replaced; I wanted to build my own product.
I started in October last year.
The reason was simple—my family member teaches lessons and often miscounted or couldn't reconcile lesson tallies in notebooks. I asked coaches and tutors around me and found everyone had the same problem: lesson counts were scattered in notebooks, Excel, or even LINE messages, with no single place for both parties to confirm.
So I created Course Kit, a lesson management tool.
I started brainstorming with a "marketing x app" concept, gradually narrowing a big vision down to the most crucial first step.
I delved into Flutter, a framework I'd never touched, developing a cross-platform app, integrating In-App Purchase and Stripe. I hit many roadblocks, but those were also the most valuable experiences.
From ideation to launching the MVP, it took 3 months. As a Flutter newbie, I was genuinely amazed I got this far.
During these 3 months, I leveraged all my past marketing knowledge and technical experience. Looking back, while technical breakthroughs were satisfying, what truly changed me was my understanding of "product building."
I want to share a few insights with you.
1. What to Build Trumps How to Build It
In the age of AI, knowing how to code is no longer the main barrier.
The real bottleneck becomes: What exactly do you want to build? And for whom?
Initially, I listed a ton of features I wanted to make, from marketing tools to learning logs. But then I asked myself one question: "If I could only build one thing, what would it be?"
The answer was lesson management, the need I mentioned earlier.
I first checked if anyone else was doing it in the market, thought through the business model, and only started building once I confirmed the direction was right.
Find people willing to pay first, then develop. This order is more important than you think.
2. Get Functionality Working Before Polishing Design
Beautiful interfaces are secondary until you've confirmed there's a need.
My approach: Get the core functionality working, confirm people will use it, then refine the interface.
However, one thing you can't skimp on is the user onboarding flow. What's the first step, what's the second? You need to plan this out. Otherwise, even with complete features, if users open the app and don't know what to do, it's all for nothing.
Another reality: AI-generated interfaces often look very similar. Open ten AI-made apps, and their home screens are almost always a large image plus three buttons. If your product lacks its own unique identity, it's easily lost in the crowd.
So my principle is: first, ensure the core value can be experienced, then, once validated by the market, spend time giving the interface its own distinct style.
3. What AI Can Do, and What Only YOU Can Do
Throughout the product development process, I gradually discovered that work can be divided into two types: one with rules, and one without standard answers.
AI excels at the first type—give it requirements, and it can write code, make features work, and even suggest technical solutions.
But for the second type, it can't help you.
For example, I wanted to add a feature, and AI confirmed it was technically feasible. But I was considering other things—"Do users really need this?" "Should I do it now, or wait for validation?"
Later, I threw these considerations at AI, and its judgment matched mine. It replied: "This feature has low risk if implemented after users actually express a need." "Doing it now will take some testing time and conflict with your expected launch date."
These problems have no formula; they rely on your understanding of the market and experience.
AI can answer "Can it be done?", but "Should it be done?" is your judgment.
This judgment is the most valuable skill when building a product solo.
4. Done is Better Than Perfect
Initially, I listed a ton of features I wanted to implement, feeling each one was crucial.
But once I started, I realized that just getting the core flow working was a huge step forward.
As an engineer, I only needed to focus on development. But as a solo product builder, you simultaneously have to think: "Will users use this feature?" and "Can this feature make me money?"
User experience and business value—you have to consider both at the same time. This is completely different from just writing code in a company setting.
Later, I learned one thing: First, make the product usable, get people to try it, then decide whether to make it better.
I uploaded the first version to the App Store and posted about it on PTT. Within 3 days, all 100 iOS promo codes were redeemed.
At that moment, I knew I was on the right track. It's okay if it's not perfect; let the market give you the answer first.
5. A New Understanding of What "Engineer" Means
These 3 months felt like being in the Hyperbolic Time Chamber.
In the past, I thought an engineer just wrote code. But after building a product solo, I realized writing code is just one part of it.
Figuring out what to build, who it's for, and how to get people to pay for it— from market analysis, user flow planning, to post-launch maintenance, each step requires a different way of thinking.
And these aren't just skills engineers need. Anyone wanting to turn an idea into a product using vibe coding will walk a similar path.
The most valuable skill isn't the ability to write code, but the ability to determine "what problem is worth solving."
This transformation redefined what the word "engineer" means to me.
6. Don't Let AI Experience Your Life for You
I've used AI for many things these past few months, but one thing I've become increasingly sure of.
AI can help you run through processes, but it can't help you "experience" that journey.
There are many ready-made prompts out there; just plug them in and get results. But if you haven't thought "what do I want?" yourself, that result is just someone else's answer.
For example: I asked AI to help me with brand positioning. It countered with: "What style do you want? Who is your audience?" I realized I had to think through these questions myself before it could truly help me.
There are no shortcuts to thinking. Skip it, and your thinking muscles will atrophy; go through it, and that understanding truly becomes yours.
AI is a great accelerator, but your life is still yours to experience.
Wrapping Up
Three months ago, I asked myself: How can an engineer break free from the contract manufacturing cycle?
My answer now isn't to learn more technical skills, but to start thinking about "what problems are worth solving."
For me, that problem was "how to stop coaches and students from using notebooks to track lesson counts." It's a small thing, but genuinely needed by some.
Furthermore, simply recording lesson counts is just the first step. The true value of the tool is reminding users "to remember to attend class" at the right time. Buying a class and not attending is like not buying it at all. Good design makes life easier.
This question isn't just for engineers.
Figure out what problem you want to solve, then walk through the journey yourself. That process is the real reward.
Have you built anything with vibe coding? I'd love to hear your story — feel free to email me anytime 😊
