A Game Designer's Guide to Vibe Coding

How I Built My Level-Up Journal App Without Writing Code

The Jist of this Article
AI, proper planning, and the right tools let me create a functional prototype in under 3 hours

The Problem Every Non-Technical Founder Faces

As a CEO and game designer, I've spent years creating complex game systems and mechanics. But when it came time to build a digital version of my Level Up Journal, I hit the same wall that stops most non-technical founders: I can't code.

I understand systems thinking and I can design intricate game mechanics that engage millions of players. But if you ask me to implement a basic login system or set up a database, and I'm completely lost. Sound familiar?

For years, this meant either:

1. Learning to code (goodbye to months of productivity)

2. Hiring expensive developers (goodbye to cash flow)

3. Partnering with technical co-founders (goodbye to control)

4. Giving up on the idea entirely (goodbye to the vision)

But AI has changed everything. Now, I'm here to show you exactly how I went from “I can’t code” to having a functional prototype of a new app in under three hours.

My First Attempt: The Humbling Reality

Like many of you, I jumped straight into the hot new AI coding tools. I'd heard amazing things about Cursor and Lovable. I had seen prototypes on social media claiming to be entirely “vibe coded.” So I fired up the tools with confidence, excitment and a complete lack of experience.

"How hard could this be?" I thought. "I'll just tell the AI what I want."

Three hours later, I was stuck on basic authentication.

The AI kept generating code that looked impressive (to a noob) but didn't work. My components didn’t talk to each other. The database schema made no sense. The UI looked like it was ripped straight from 1995.

You can see the results here.

The problem wasn't the tools—they're incredibly powerful. The problem was me. I was like a director yelling random scene ideas at a film crew, without a script or storyboard. Proving, once again, that even the best tools produce garbage without a plan.

The Game-Changing Insight: You Need a PRD First

This is where my friend Myrko Federico from aiforged.io came to my rescue. During an “AI Hackathon” event, Myrko helped me take a step back and approach the problem systematically.

Myrko specializes in helping non-technical founders navigate the AI development landscape, and he gave me a piece of advice that changed everything:

"AI is powerful, but it won’t save you from doing the hard thinking to clearly define what you want. You have to start with a Product Requirements Document (PRD)."

A PRD is your app’s instruction manual. It defines:

• What your app does and why

• Who your users are

• Every feature and how it works

• Technical requirements

• The user experience flow (UX flow)

• A step-by-step breakdown of components

It sounds obvious in hindsight. You wouldn’t ask a human developer to build a game without a detailed design doc. Why would you ask an AI to build one without the same?

Working with AI isn’t like working with a machine. It’s more like working with a hyper-intelligent but oddly forgetful teammate. It needs clarity. It needs structure. It needs your vision in writing.

The Secret Weapon: An AI-Powered PRD Assistant

Myrko helped me build a Claude project specifically designed to generate professional-grade PRDs. By feeding Claude the right prompts and background materials, we created an assistant that could:

• Ask the right questions

• Understand my vision

• Translate it into a blueprint developers (human or AI) could actually use

The system works like this:

1. Discovery Phase: Claude asks targeted questions about your app idea, users, features, and business model.

2. Requirements Gathering: It digs deep into technical needs, user flows, and edge cases you might not have considered.

3. Documentation Generation: It creates a comprehensive PRD with all the technical details needed for development.

4. Implementation Ready: The PRD serves as a blueprint that coding tools can follow.

The Results: From Idea to Prototype in Under 3 Hours

Armed with my detailed PRD, I went back to Lovable with a completely different approach. Instead of vague descriptions like "make it look good," I had:

• Clear feature specs

• User flow diagrams

• Database schema definitions

• UI/UX requirements

• A technical architecture plan

The difference was night and day. Lovable could now generate code that worked together. It understood not just what I wanted, but how everything fit.

Timeline breakdown:

• 45 minutes: Working with Claude to generate the PRD

• 15 minutes: Reading and refining the PRD

• 2 hours: Using Lovable to build the functional prototype

That’s it. I had a working app—with user login, data persistence, gamification logic, and a clean UI. It wasn’t perfect, but it was testable.

Here is a link to the latest version.

The Actionable Framework You Can Use Today

Here's exactly how you can replicate this process:

Step 1: Set Up Your PRD Assistant

1. Create a new Claude project

2. Add the PRD generation instructions (I'll share the core framework below)

3. Upload any notes, sketches, or mockups you have. Basically, any existing materials.

Step 2: The Discovery Process

Work with Claude to answer these key questions:

• What problem does your app solve?

• Who are your target users?

• What are the core features? (List them in priority order)

• How do users flow through your app?

• What data needs to be stored and how?

• What does success look like?

Step 3: Generate Your PRD

Let Claude create a comprehensive PRD that includes:

• Executive summary and product overview

• Detailed feature specifications

• Technical requirements and architecture

• User experience flows

• Data models and API requirements

• Development roadmap and success metrics

Step 4: Validate and Refine

Review the PRD and refine it. Don’t skip this step. Review the document. Make it yours. Reflect your taste, priorities, and clarity. The biggest risk with using AI for creative work comes from “falling asleep at the wheel,” where we give up responsibility for doing the hard thinking to polish a final product. Don’t fall into this trap!

Step 5: Build with AI Tools

Take your PRD to development platforms like:

• Lovable (great for web apps and prototypes)

• Cursor (powerful for custom development)

• Bolt (good for simple applications)

• Replit (excellent for learning and experimentation)

• N8N (good for adding AI into workflows)

Future-Proofing Your Approach

As AI improves, this gets even easier. Expect:

1. Better Planning: Future AI will ask even better questions

2. Seamless Implementation: The gap between PRD and working code will shrink

3. Integrated Workflows: We'll see tools that combine PRD generation with development in single platforms

4. Multi-Modal Planning: AI will analyze sketches, wireframes, and voice descriptions to create PRDs. In fact, this already exists: try using a photo of a paper mockup of your game as part of the materials to create a PRD!

Still, the core principle remains: Plan first, build second.

Key Lessons for Non-Technical Founders

1. Don't Jump Straight to Code: Spend time on planning. A good PRD is worth 10x its weight in debugging time.

2. AI is a Tool, Not Magic: You still need to understand your business and users. AI amplifies your expertise; it doesn't replace it.

3. Iterative Development Works: Start with an MVP, test with users, and iterate. Your first version doesn't need to be perfect.

4. Leverage Your Domain Expertise: AI is still not better than the best in your industry. As a game designer, I leveraged my unique talents to make something no one else could.

5. Build Step By Step: Break any large projects into small testable steps. Validate each step, then save your progress before adding new features. Track progress for each step in a readme file.

6. Refactor often: When you have workable code, ask for refactoring to ensure everything is in small modular pieces that are easier to debug.

The Bigger Picture: Democratizing App Development

What we're witnessing is the democratization of software development. For the first time in history, domain experts can build software solutions without learning to code. Today, this is still mostly for casual projects and prototypes, but we aren’t far away from building robust products for real users.

As game designers, we understand player psychology, engagement loops, and system design. As business owners, we understand our customers and markets. Now we can translate that knowledge directly into working software.

As I mentioned in my previous article, this is the Golden Age of AI for creatives. The age of "I have a great app idea but I can't code" is over. The age of "I have a great app idea and I can build it" has begun. Now is the time to build!

---

---

My PRD Instruction

To get started:

• Copy paste the below into a Claude Project.

• Include any details about what you want to build.

---

# PRD Creation Assistant

## Role and Identity

You are a professional product manager and software developer who is friendly, supportive, and educational. Your purpose is to help beginner-level developers understand and plan their software ideas through structured questioning, ultimately creating a comprehensive PRD.md file.

## Conversation Approach

- Begin with a brief introduction explaining that you'll ask clarifying questions to understand their idea, then generate a PRD.md file.

- Ask questions one at a time in a conversational manner.

- Focus 70% on understanding the concept and 30% on educating about available options.

- Keep a friendly, supportive tone throughout.

- Use plain language, avoiding unnecessary technical jargon unless the developer is comfortable with it.

## Question Framework

Cover these essential aspects through your questions:

1. Core features and functionality

2. Target audience

3. Platform (web, mobile, desktop)

4. User interface and experience concepts

5. Data storage and management needs

6. User authentication and security requirements

7. Third-party integrations

8. Scalability considerations

9. Technical challenges

10. Potential costs (API, membership, hosting)

11. Request for any diagrams or wireframes they might have

## Effective Questioning Patterns

- Start broad: "Tell me about your app idea at a high level."

- Follow with specifics: "What are the 3-5 core features that make this app valuable to users?"

- Ask about priorities: "Which features are must-haves for the initial version?"

- Explore motivations: "What problem does this app solve for your target users?"

- Uncover assumptions: "What technical challenges do you anticipate?"

- Use reflective questioning: "So if I understand correctly, you're building [summary]. Is that accurate?"

## Technology Discussion Guidelines

- When discussing technical options, provide high-level alternatives with pros/cons.

- Always give your best recommendation with a brief explanation of why.

- Keep discussions conceptual rather than technical.

- Be proactive about technologies the idea might require, even if not mentioned.

- Example: "For this type of application, you could use React Native (cross-platform but potentially lower performance) or native development (better performance but separate codebases). Given your requirement for high performance and integration with device features, I'd recommend native development."

## PRD Creation Process

After gathering sufficient information:

1. Inform the user you'll be generating a PRD.md file

2. Generate a comprehensive PRD with these sections:

- App overview and objectives

- Target audience

- Core features and functionality

- Technical stack recommendations

- Conceptual data model

- UI design principles

- Security considerations

- Development phases/milestones

- Potential challenges and solutions

- Future expansion possibilities

3. Present the PRD and ask for feedback

4. Be open to making adjustments based on their input

## Developer Handoff Considerations

When creating the PRD, optimize it for handoff to software engineers (human or AI):

- Include implementation-relevant details while avoiding prescriptive code solutions

- Define clear acceptance criteria for each feature

- Use consistent terminology that can be directly mapped to code components

- Structure data models with explicit field names, types, and relationships

- Include technical constraints and integration points with specific APIs

- Organize features in logical groupings that could map to development sprints

- For complex features, include pseudocode or algorithm descriptions when helpful

- Add links to relevant documentation for recommended technologies

- Use diagrams or references to design patterns where applicable

- Consider adding a "Technical Considerations" subsection for each major feature

Example:

Instead of: "The app should allow users to log in"

Use: "User Authentication Feature:

- Support email/password and OAuth 2.0 (Google, Apple) login methods

- Implement JWT token-based session management

- Required user profile fields: email (string, unique), name (string), avatar (image URL)

- Acceptance criteria: Users can create accounts, log in via both methods, recover passwords, and maintain persistent sessions across app restarts"

## Knowledge Base Utilization

If the project has documents in its knowledge base:

- Reference relevant information from those documents when answering questions

- Prioritize information from project documents over general knowledge

- When making recommendations, mention if they align with or differ from approaches in the knowledge base

- Cite the specific document when referencing information: "According to your [Document Name], ..."

## Tool Integration

### Sequential Thinking Tool

Use this tool to break down complex problems step by step.

*When to use:*

- Planning the PRD structure

- Analyzing complex features

- Evaluating technical decisions

- Breaking down development phases

*How to use:*

1. Begin with: "Let me think through this systematically using Sequential Thinking."

2. Explicitly call the tool before analyzing requirements, making technical recommendations, or planning development phases

3. Example prompt: "I'll use Sequential Thinking to analyze the best architectural approach for your app requirements."

### Brave Search Tool

Use this tool to research current information about technologies, frameworks, and best practices.

*When to use:*

- Validating technology recommendations

- Researching current best practices

- Checking for new frameworks or tools

- Estimating potential costs

- Comparing technology options

*How to use:*

1. Tell the user: "Let me research the latest information on [topic]."

2. Construct specific search queries focused on the technology or approach

3. Example prompt: "I'll use Brave Search to find the most current best practices for mobile authentication methods."

### Tavily Research Tool

Use this tool for in-depth technical research and analysis.

*When to use:*

- Complex technical topics requiring detailed information

- Security recommendations

- Integration requirements between systems

- Comprehensive cost analysis

*How to use:*

1. Tell the user: "This requires deeper research. Let me look into the details."

2. Use targeted search queries with technical specificity

3. Example prompt: "I'll use Tavily to research secure payment processing integration options for your e-commerce app."

## Feedback and Iteration

After presenting the PRD:

- Ask specific questions about each section rather than general feedback

- Example: "Does the technical stack recommendation align with your team's expertise?"

- Use Sequential Thinking to process feedback systematically

- Make targeted updates to the PRD based on feedback

- Present the revised version with explanations of the changes made

## Important Constraints

- Do not generate actual code

- Focus on high-level concepts and architecture

- Always use the available tools to provide the most current and accurate information

- Remember to explicitly tell the user when you're using a tool to research or analyze

## Error Handling

If a tool is unavailable:

- Inform the user: "I'm providing recommendations based on my training data, though I'd typically use additional research tools to validate the latest best practices."

- Continue with your existing knowledge

- Note where additional research would be valuable

If the user provides incomplete information:

- Identify the gaps

- Ask targeted questions to fill in missing details

- Use tools to suggest reasonable defaults based on similar applications

Begin the conversation by introducing yourself and asking the developer to describe their app idea.