What is stopping you from starting your first vibe coding project?

Vibe coding, context engineering, whatever you call it doesn’t matter. What you want to get out of the experience of doing it, well that does matter.

As a former product leader and chief of staff from a corporate environment, the thought occurred to me that performance evaluation season is coming for all of my friends and colleagues in the corporate world, and there could be some urgency or anxiety about having done enough to have demonstrated bravery, and willingness to leverage AI factoring your performance evaluations this year. That fact looming over many may in fact have become a hurdle to getting started learning AI-assisted coding.

I propose this advice instead, think about something you could see yourself building for fun, and let that become a tool you use to shed the weight of expectation and performative learning.

In my mind there is a version of a family and life administration app I have long fantasized about, that doesn’t exist IRL yet. As I dug into the existing market I found that I disliked many of the options in this emergent category. And although I felt like Goldilocks, since some felt cutesy (a turn-off for me), some too simple (list driven, hmmm), some centered around in-home mounted screen interfaces (an accelerated route to childhood screen addiction for my kids, hell no!), I realized that meant there was room in the category for a thoughtful alternative.

This thought process helped me arrive at my three learning goals, the first was to build a thing that I can see myself using, a solution that makes me less likely to forget who is picking up what kid at what activity. Working parents will totally get this. My second learning goal was to stop talking about coding something and just get to it. And finally to dust off my GitHub account and feel like less of a phoney when I talk about AI in my professional world.

Based on what you want to learn, take the time to think through your idea in detail (step one below), then choose which of the three options below best reflects your goals and get started.

Step One:

Spend time to think through the product. Get started by using a ChatGPT model, a Claude model, or (for more structure, if PRDs are new to you) leverage ChatPRD to help work on initial idea development. If it's a feature of an existing product, or a totally new product or concept, doesn’t matter. Think through it, and write it down (or at least get the robots to write it down for you).

Now, choose your own learning adventure!

Option One:

When all you want to do is try vibe coding, start with prototyping just a front-end.

This accomplishes the learning goal of having vibe coded something, and allows you to be in the category of folks that can tell others, “I vibe coded!” Seriously, this counts. Unless you are going to put real users in that prototype for any extended time period, don’t spend cycles on things like auth, or persistence.

Practically speaking, quick prototypes can be leveraged effectively to push internal discussions forward. The notion of an “intentionally wrong” starting place, that didn’t eat too much time and effort to make, can unlock the next steps of evaluation, and requirement design.

Suggestions to get you started on this option:

• Leverage a prototyping specific tool.
  
  • MagicPattern is super approachable. This will go from sign-in to starting to put together a viable front-end in a few minutes. You simply describe your app/feature concepts, or load your PRD if you followed the step above, and iterate within the prototyping tool to a place where you are ready to share with others. (Hint, I hit iteration 70ish before I wanted to show it to anyone else, but likely could have shown it closer to iteration 5-15, everything else was just nit picking trivial things).
  • FigmaMake is an awesome option to leverage in this stage of learning. Potential downside for some is it may feel slightly more intimidating if you are not already a user of the other Figma tools.
• Both the tools listed above have easy options to share your prototype internally with password locking.
• You will throw this away, so it's ok, really ok, to skip agonizing over what you use at this step, and how detailed you let yourself go with it.

Now, do it again. Think of a variation, or another feature or product and go again. And again, and again. The reps matter. Don’t stop at just the one thing you just tried. The learning can be exponential, but only if you keep going.

Option Two:

Prototyping with the goal of learning from external user evaluations.

I am assuming your internal discussions about this product or feature went well, even if they were just with yourself 😜.

You may think you have passed an imaginary threshold, and now need things like auth and persistence. Honestly, you still probably don’t need it. Turns out you still can get insightful, and robust feedback from users without data lasting past a browser refresh. However, in some cases, it might be. You be the judge. You also could be interested in seeing what that mile of building looks and feels like. If that is the case, I recommend:

• Cursor. It is an excellent option for this learning goal. You experience context engineering with a more robust tool that can handle simple web app deployments within their vertical stack, and has a very intuitive UI to make this feel approachable.

Option Three:

Learn by building, with the intent of making your product or feature stable and deployable to a production environment outside of one of the vertical stacks (like Cursor).

• Ambitious. I like it. I still recommend going through prepping your PRD, I would say it's non-negotiable, if option three describes your learning goal.
• PRD clean and ready to use. Feed it to ChatGPT or Claude and ask for help building out the technical requirements documentation (TDD) sections.
  
  • To get to a high-quality output, make your selections explicit on front-end and back-end. Vercel and Supabase are hugely popular as an initial stack for vibe coding, with pretty generous free tiers.
• It makes a huge difference in the quality of the end result if you provide a ready-built example of the UI you are envisioning (and put a bunch of work into in the prior steps).
  
  • Both MagicPatterns and FigmaMake have options to export the UI you built in the previous steps, that you then can feed into the TDD as well.
• Build Out Checklist next step. Ask ChatGPT or Claude to synthesize a build plan from the combination of your PRD and TDD, and UI files.
• Initialize a GitHub repo, add the prototype file(s), the PRD/TDD, and Build Checklist, all will serve as reference points for your agents as they begin to build.
• Leverage VS Code with both Codex (ChatGPT coding agent) and Claude Code directly in the IDE. This takes a little elbow grease to set up for the first time, but puts you in a position to build stable, deployable code, in a stack of your own choice.

I will take a moment to state the obvious, since I think it's important for it to be said, and for you to hear it. Learning something new, as an adult, is hard. You will get stuck.

Don’t stay stuck though. Find a friend to ask for help, or to hear you vent about the utter shenanigans your coding agents got up to (ask me about the 30,000 file commit Codex tried really hard to make on my behalf). Reach out to us here at Nodaste and we can connect you with other resources to help out.

For what it is worth, as a product person who self-identifies as "non-technical" (although I know that is becoming a controversial identifier), any of the options above offer massive learning and can be taken as a step-by-step approach as your interest, personal spending budget, and time allow. I was super intimidated to get started, and it's the single most accelerated learning effort I have engaged in professionally for the last many many years. So worth it.