landing
simulation
review insight
review insight2
review insight3
review insight4
interview insight
interview insight2

Persona Theater - Kiroween Hackathon Submission

AI-Powered Product Validation Platform: Simulate 100 Customer Personas Before Building Your Product

Inspiration

The Problem I Couldn't Ignore

67% of startups fail because they build products nobody wants. That's not just a statistic—it's $75,000-$200,000 and 6-18 months of wasted effort per failed venture.

As the founder of Leda Games for 4 years—a company specializing in making Webtoon or TV shows into games—I've experienced this pain firsthand. I've gone through successful crowdfunding (120 million won on Tumblbug), Pre-A investment from Kakao Games, and partnerships with Naver and TVING. But I've also experienced the devastating reality of building products that didn't find their market fit. Traditional market research costs $10,000-$50,000 and takes weeks. Quick surveys give shallow insights. And by the time you validate your idea, the market has moved on.

The Spark

I asked myself: What if AI could simulate an entire market response before you write a single line of code?

What if you could interview 100 potential customers—each with distinct personalities, skepticism levels, and decision-making patterns based on real behavioral economics research—in under 10 minutes?

Persona Theater was born from this question. Not as another chatbot, but as a virtual theater where AI personas perform the drama of market adoption, complete with rationalization loops, loss aversion, and status quo bias.

What it does

Persona Theater is an AI-powered product validation platform that transforms your product idea into a full market simulation within minutes.

Core Features

1. Intelligent Idea Parsing

Paste any idea (even a rambling voice memo transcription)
AI extracts structured product requirements automatically
Generates comprehensive PRD (Product Requirements Document)

2. Strategic Persona Generation

Creates 100 diverse AI personas based on behavioral economics principles
5 Strategic Groups: Positive Adopters (25%), Expandable (30%), Critical Evaluators (20%), Alternative Seekers (15%), Monetization Core (10%)
Each persona has unique traits: skepticism, loss aversion, status quo bias, spending power, impulsiveness

3. Real-Time Market Simulation

Watch personas explore, evaluate, and decide on your product
Live visualization of adoption patterns and churn points
Behavioral Economics Engine v6.0 with:
- Loss aversion calculations (Kahneman & Tversky model)
- Rationalization loops (up to 3 self-persuasion attempts)
- Status quo bias dynamics

4. Authentic Review Generation

AI generates realistic customer reviews (1-5 stars)
Reviews match persona personality and decision rationale
Distribution follows real-world patterns (Amazon/Yelp 2024 data)

5. Interactive Persona Interviews

Chat with any persona using Dynamic Chain-of-Thought (D-CoT)
Adaptive reasoning depth based on question complexity
Get deep insights into objections, preferences, and recommendations

6. 10-Stage E2E Validation Pipeline (modules completed but didn't have enough time to implement them all)

Structured Input → Idea Scoring → PRD Generation → Expert Feedback
→ Persona Generation → Simulation → Quantitative Analysis
→ Deep Analysis → Review Generation → Interactive Interviews

7. Market Research Integration

Real-time data from Brave Pro AI + Google grounding search
Competitor analysis with pricing, features, and positioning
User pain points from Reddit/HackerNews discussions

How I built it

A Non-Developer's Journey with Kiro

Here's my confession: I'm not a developer. I'm an entrepreneur who's spent 7 years building immersive game experiences. When I started this project, I couldn't write a proper React component from scratch. But I had a vision, and Kiro gave me the tools to bring it to life.

The Philosophy: Spec-Driven Development is Everything

For a non-developer like me, spec documents aren't optional—they're survival. Early in the hackathon, I learned a painful lesson: vague instructions lead to over-engineering, which leads to error cascades I couldn't debug.

I developed a strict personal rule:

"Code should be flexible. Requirements always change. Business expands, ideas evolve. Rewriting code every time is not sustainable. To be flexible, code must be lightweight."

My biggest enemy? Over-engineering. Vague instructions cause AI to over-interpret, generating unnecessary code that destroys consistency, stability, and readability all at once.

The Modular Architecture Principle

I believe in strict Presentation / Business Logic separation:

Layer	Responsibility	Changes When...
Presentation	User input/output, UI rendering	Design changes
Business Logic	Core functionality, rules, state transitions, validation	Business rules change

This separation was non-negotiable. Without it, errors became unmanageable, and modifications snowballed into chaos.

My Spec Creation Workflow

Unlike most developers who generate requirements.md, design.md, and tasks.md in one session, I created them across 6 separate sessions—each with careful review:

Session 1: Requirements Analysis
    ↓ Review & Refine
Session 2: Requirements Finalization (EARS Pattern)
    ↓ Review & Refine
Session 3: Design Document - User/Data Flow
    ↓ Review & Refine
Session 4: Design Document - Module Architecture
    ↓ Review & Refine
Session 5: Tasks Generation (with PBT)
    ↓ Review & Refine
Session 6: Tasks Validation & MCP Workflow Integration

Yes, this consumed more tokens. But fixing errors and re-implementing features later would have cost far more. For a non-developer, meticulous spec creation is actually token-saving.

Custom Hook for Spec Generation

I created a manual hook that enforced my modular design philosophy:

## Spec Generation Hook

Before implementing any requirement, execute modular design:

1. Analyze requirements → Create detailed user flow, data flow
2. Explore codebase → Identify conventions, guidelines
3. Design modules and work locations
   → MANDATORY: Separate Presentation / Business Logic

Respond in single markdown with:
- Overview: Module names, locations, brief descriptions
- Diagram: Mermaid syntax for module relationships
- Implementation Plan: Concrete plans for each module
  - Presentation: Include QA sheet
  - Business Logic: Include unit tests

Task Execution Hook

Every task execution followed a strict protocol:

#Current File(task) 
!!ALWAYS USE SERENA MCP ALL THE TOOLS ALL THE TIME!!

execute Phase{} Task {} (--ULTRA THINK)

MANDATORY WORKFLOW:
1. Explore codebase → Identify all files/folders
2. Break large tasks into small units
3. Use Serena MCP for ALL file operations
4. Research first (Brave, Exa, Ref) for best practices
5. Sequential thinking from beginning to end
6. Memory at start and end

The MCP Workflow That Changed Everything

I developed a Compounding Engineering approach using 13 MCPs:

┌─────────────────────────────────────────────────────────────┐
│  1. 💾 Memory MCP - Load best practices from past sessions  │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  2. 🔍 Serena MCP - Analyze codebase, find symbols          │
│     • get_symbols_overview                                   │
│     • find_symbol                                            │
│     • find_referencing_symbols                               │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  3. 🌐 Research MCPs - Best practices & solutions           │
│     • Brave Search (Pro AI level)                            │
│     • Exa MCP (web_search, deep_researcher, code_context)    │
│     • Ref MCP (official documentation)                       │
│     • Firecrawl MCP (web scraping)                           │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  4. 📖 Context7 MCP - Library documentation                 │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  5. 🔧 Serena MCP - Symbol-level code editing               │
│     • replace_symbol_body                                    │
│     • insert_after_symbol                                    │
│     • insert_before_symbol                                   │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  6. 🧪 Chrome DevTools MCP - Browser verification           │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  7. 💾 Memory MCP - Save learnings for future sessions      │
└─────────────────────────────────────────────────────────────┘

This workflow wasn't just about using tools—it was about accumulating knowledge across sessions. Every lesson learned was saved to Memory, making each subsequent task execution smarter.

EARS Requirements & Property-Based Testing

I enforced EARS (Easy Approach to Requirements Syntax) for all acceptance criteria:

## EARS Patterns I Used

1. Ubiquitous:    THE System SHALL [response]
2. Event-Driven:  WHEN [trigger], THE System SHALL [response]
3. State-Driven:  WHILE [condition], THE System SHALL [response]
4. Unwanted:      IF [condition], THEN THE System SHALL [response]
5. Optional:      WHERE [option], THE System SHALL [response]

When Kiro 0.6 GA introduced PBT (Property-Based Testing), I immediately integrated it:

## Correctness Properties

**Property 1: Persona Generation Validity**
*For any* product input, generating personas should produce exactly 100 personas distributed across 5 strategic segments.
**Validates: Requirements 2.1, 2.2**

**Property 2: Simulation Determinism**
*For any* identical simulation parameters, running the simulation twice should produce statistically similar adoption patterns (within 5% variance).
**Validates: Requirements 3.1, 3.3**

The Test-Before-Integration Rule

As a non-developer, I couldn't afford integration failures. My rule:

"Never integrate a module without first testing it in isolation."

For every feature:

Build the module
Create a dedicated test page
Verify visually and functionally
Only then integrate into the main application

This added time but saved countless hours of debugging integration issues.

Phase Validation Tasks

Every phase in my tasks.md ended with a mandatory validation task:

- [ ] X.9 Phase X 완료 검증 (0.5일)
  - **목적**: Phase X의 모든 구현이 완료되었는지 검증
  - **🔍 Serena 검증**: `find_symbol`로 심볼 존재 확인
  - **검증**: 파일 존재 확인, 기능 동작 확인, 빌드 성공 확인, 누락 기능 구현, 버그 수정

Initially, I manually asked "verify everything is implemented, fix bugs, complete missing parts" after each task. Then I realized: why not make it an explicit task? This became standard in my template.

Technical Architecture

Frontend (React 18.3.1 + TypeScript 5.7.3)

Vite for blazing-fast builds
Zustand for state management (9 specialized stores)
TanStack Query for server state
Framer Motion for smooth animations
shadcn/ui for polished components (customized, never default)
i18next for internationalization (English + Korean)

Backend (Supabase Edge Functions)

16+ Deno-based edge functions
Serverless architecture for global low-latency
Upstash Redis for caching

AI/LLM Integration

Google Gemini 2.5 Flash (primary LLM)
Brave Pro AI (market research)
Custom D-CoT implementation for adaptive reasoning

Key Libraries

{
  "react": "18.3.1",
  "typescript": "5.7.3",
  "zustand": "5.0.2",
  "@tanstack/react-query": "5.66.1",
  "framer-motion": "11.15.0",
  "@supabase/supabase-js": "2.49.1",
  "zod": "3.24.1",
  "i18next": "24.1.0"
}

Kiro Usage Statistics

Category	Count	Details
Specs Created	21	Full requirements → design → tasks cycles
Hooks	4	Spec generation, task execution, validation, deployment
Steering Files	14	Manual, conditional, and always-active
MCPs Used	13	Serena, Memory, Brave, Exa, Ref, Context7, Supabase, Shadcn, Chrome DevTools, etc.
Powers	5	Research, Code Implementation, Design, Thinking, Testing

Vibe Mode vs Spec Mode: 50/50

My development split was roughly half Vibe mode, half Spec mode:

Spec Mode: Complex features requiring careful planning
Vibe Mode: Incremental additions, assembling modular pieces

Because I enforced modular architecture, I could use Vibe mode to add small, self-contained features that snapped together like LEGO blocks.

Power Feature Discovery

Near the end of the hackathon, my account was updated to include Powers. The impressive part: MCPs weren't just converted 1:1 to Powers. Instead, they were grouped by purpose:

Power	Purpose
Research Power	Brave + Exa + Ref combined
Code Implementation Power	Serena + Context7
Design Power	Shadcn + Frontend guidelines
Thinking Power	Sequential thinking + Memory
Testing Power	Chrome DevTools + Validation

This purpose-driven organization made context-switching seamless. I regret not having more time to refine these Powers further.

Challenges I ran into

1. The Non-Developer's Error Cascade

Challenge: As a non-developer, when errors occurred, I often couldn't diagnose them. One error would lead to a "fix" that created three more errors.

Solution: I adopted atomic development principles—one item at a time, always compilable, always testable. My steering file enforced:

## Atomic Development Rules

- Single component per task
- Test written BEFORE implementation
- Build must compile after EACH change
- STOP immediately on build failure
- Never work on frontend while backend is incomplete

2. Behavioral Economics Accuracy

Challenge: How do you simulate human decision-making without being cartoonish?

Solution: I deep-dived into academic research—Kahneman & Tversky's loss aversion model, status quo bias studies, and rationalization psychology. I implemented a "rationalization loop" where personas can attempt self-persuasion up to 3 times before making a final decision. This creates realistic hesitation and justification behaviors.

3. Review Generation Authenticity

Challenge: AI-generated reviews often feel robotic with perfect grammar and uniform sentiment.

Solution: I implemented Fisher-Yates shuffle for queue ordering and research-based rating distributions (52% 5-star, 25% 4-star, etc.). I also injected persona-specific writing styles—some verbose, some terse, matching their personality traits.

4. The Over-Engineering Trap

Challenge: Early in development, AI would generate elaborate solutions for simple problems, creating unmaintainable code.

Solution: I created steering files that explicitly forbade over-engineering:

## Anti-Over-Engineering Rules

❌ NEVER assume requirements beyond what's stated
❌ NEVER add "helpful" features not requested
❌ NEVER create abstractions "for future use"
✅ ALWAYS implement minimum viable solution
✅ ALWAYS ask before expanding scope

5. Task Breakage in Kiro

Challenge: My tasks.md files would break in Kiro execution—tasks would get cut off mid-flow.

Solution: After painful debugging, I discovered the cause: validation checklists with - [ ] items were being parsed as separate tasks. I created a strict format rule:

❌ WRONG (causes breakage):
**✅ 검증**:
- [ ] Item 1  ← Parsed as separate task!
- [ ] Item 2  ← Parsed as separate task!

✅ CORRECT (no breakage):
- **검증**: Item 1 확인, Item 2 확인, Item 3 확인

This became mandatory in my tasks-format.md steering file.

6. The "No Assumptions" Policy

Challenge: AI would make assumptions about my preferences, technical choices, and environment setup, leading to misaligned implementations.

Solution: I enforced a strict response structure:

FACT: [Objective statement of current state]
SOLUTION: [Exact command or action needed]
QUESTION: [Direct question asking for user decision]

No assumptions. Only facts, solutions, and questions.

Accomplishments that I'm proud of

As a Non-Developer

Built a production-ready SaaS with ~73,000 lines of TypeScript—something I couldn't have imagined 3 weeks ago
Developed a systematic workflow that other non-developers can learn from
Proved that spec-driven development can bridge the gap between vision and implementation

Technical Achievements

Behavioral Economics Engine v6.0 implementing Kahneman & Tversky's loss aversion model
Dynamic Chain-of-Thought (D-CoT) - adaptive reasoning system with 4 question types and 2-5 step generation
16 Edge Functions providing serverless AI orchestration
Strategic Persona Segmentation across 5 market segments for realistic distribution
Real-time simulation engine with physics-based movement and utility calculations

Product Achievements

10-stage E2E validation pipeline covering idea-to-insights journey
Bilingual support (English + Korean) with 20+ i18n namespaces
Premium UI design with Framer Motion animations and Neo-brutalism aesthetics
Market research integration with live Brave Pro AI data

Process Achievements

21 complete spec cycles with requirements → design → tasks
Compounding Engineering through Memory MCP—each session smarter than the last
Zero-assumption development with explicit fact/solution/question patterns
Modular architecture enabling safe incremental development

Validation Metrics

85-95% accuracy matching real human behavior (based on Stanford/Google synthetic persona studies)
100 personas generated per validation session
<10 minutes for complete product validation cycle
$260B market problem addressed (wasted startup investment annually)

What I learned

About Being a Non-Developer Building Software

Specs are your safety net: When you can't debug intuitively, detailed specs prevent the need to debug at all.
Modular architecture is survival: Presentation/Business Logic separation isn't academic—it's the difference between manageable errors and cascading failures.
Test in isolation, integrate with confidence: Never integrate untested modules. The 30 minutes spent on a test page saves 3 hours of integration debugging.
Over-engineering is the enemy: Vague instructions create elaborate solutions. Be specific, be minimal.

About Kiro-Driven Development

Spec-driven development scales: What felt slow initially became my superpower. Kiro specs kept me aligned as complexity grew.
Steering files are underrated: Simple markdown files prevented countless AI mistakes. I wish I'd started with more detailed steering earlier.
MCP workflows compound: The Memory → Research → Implement → Save cycle meant each session built on previous learnings.
Hooks enforce discipline: Manual hooks for spec generation and task execution ensured consistency across 3 weeks of development.
Powers organize complexity: Grouping MCPs by purpose (not by tool) made context-switching intuitive.

About Product Validation

Persona segmentation matters: Random personas give random results. Strategic distribution reflects real market dynamics.
Reviews reveal more than surveys: When personas write reviews, they justify decisions. This surfaces objections that checkbox surveys miss.
Failure analysis is gold: Understanding why personas churn teaches more than celebrating conversions.

About Hackathons

Process beats heroics: Sustainable 3-week development requires systems, not late-night sprints.
Document everything: My steering files became a knowledge base I'll use beyond this hackathon.
The joy is in the journey: Learning Kiro, building workflows, solving problems—this was genuinely fun.

What's next for Persona Theater

My Core Belief

I don't believe Persona Theater will completely replace traditional market research or real user interviews. But I do believe it can become an invaluable complementary tool—one that democratizes the first step of product validation for anyone with an idea.

My mission is simple: Lower the barrier to product validation so that no good idea dies from lack of initial feedback.

Immediate Focus: Accuracy & Reliability

1. Validation Against Real-World Data

Partner with startups to compare Persona Theater predictions against actual launch results
Build a public "Prediction Accuracy Dashboard" showing how simulated adoption rates matched reality
Continuously refine the Behavioral Economics Engine based on real-world discrepancies
Publish findings openly to build trust and invite community improvement

2. Industry-Specific Persona Libraries

Create validated persona templates for different domains:
- B2B SaaS: IT decision-makers, procurement officers, end users
- Consumer Apps: Early adopters, mainstream users, late majority
- E-commerce: Impulse buyers, research-heavy shoppers, price-sensitive customers
- Healthcare: Patients, caregivers, healthcare providers
Each library backed by behavioral research, not assumptions

3. Bias Detection & Transparency

Show users where the simulation might be overconfident or underconfident
Highlight which persona segments have the highest uncertainty
Provide "confidence intervals" for adoption predictions
Be honest about limitations—this builds trust

Accessibility & Inclusivity

1. Generous Free Tier

Unlimited idea parsing for everyone—no barriers to starting
3 full simulations per month free forever
Full persona interview access for generated personas
Goal: Anyone, anywhere, can validate their first idea for free

2. Multi-Language Expansion

Current: English + Korean
Next: Spanish, Japanese, Portuguese, French, German
Not just UI translation—culturally adapted persona behaviors
Regional market research integration

3. Accessibility Standards (WCAG 2.2 AA)

Full keyboard navigation
Screen reader optimization
High contrast mode
Reduced motion options
Accessible PDF/report exports

4. Low-Bandwidth Mode

Lightweight version for users with slow internet connections
Offline report viewing
SMS-based simple validation for emerging markets

Ease of Use Improvements

1. Zero-Friction Onboarding

"Paste your idea and press Enter"—nothing more needed
Interactive tutorial with sample ideas
Pre-built example simulations to explore before committing
Mobile-first experience (most entrepreneurs think on the go)

2. Natural Language Everything

Ask questions in plain language: "Who would hate this product and why?"
Request specific analyses: "Compare adoption between Gen Z and Millennials"
Generate reports in conversation: "Give me the 3 biggest red flags"

3. Guided Interpretation

Don't just show data—explain what it means
"Here's what these results suggest for your next step"
Actionable recommendations, not just metrics
Connect simulation insights to concrete actions

The Vibe Coding Era: Link-Based Validation

1. From Text to Live Product Analysis

We're entering an era where vibe coding is becoming mainstream. Cursor, Bolt, Lovable, Replit Agent—these tools are enabling anyone to ship MVPs in hours, not months. This means more ideas will exist as actual deployed products, not just descriptions.

Persona Theater will evolve to meet this reality:

Paste a URL, get validation: Just drop your deployed MVP link
AI crawls and understands your product: Analyzes UI, features, copy, pricing
Personas interact with the real thing: Not imagining a product—evaluating what exists
Feedback grounded in reality: "The onboarding flow confused me at step 3" instead of abstract opinions

This shifts validation from "Would you use something like this?" to "Here's what I think of what you actually built."

2. Comparative Analysis

Paste your MVP link alongside competitor links
AI personas compare experiences directly
"I prefer Product A's pricing but Product B's interface"
Real competitive intelligence, simulated at scale

Fully Autonomous Validation Pipeline

1. AI Interviewer Meets AI Personas

Recently, Claude Code demonstrated AI conducting user interviews. This inspired a vision:

What if an AI interviewer systematically interviewed all 100 AI personas—automatically?

The workflow becomes:

Paste idea or link → That's it. You're done.
AI Interviewer activates → Conducts structured interviews with each persona
Deep-dive conversations → Follows up on objections, explores preferences
Wait and receive → Complete insight reports and interview transcripts delivered

No more manual interaction required. Just submit and receive:

Executive Summary: Key findings in 2 minutes
Full Interview Transcripts: 100 detailed conversations
Segment Analysis: Breakdown by adopter type
Risk Report: Top reasons for potential failure
Opportunity Report: Unexplored value propositions

2. Scheduled Re-Validation

Set up recurring validation as you iterate
"Re-run interviews every week as I update my MVP"
Track how persona sentiment changes with each iteration
Build a longitudinal view of product-market fit progress

Community & Open Contribution

1. Open Persona Contributions

Users can submit persona templates based on their domain expertise
Community voting on persona accuracy
Attribution and recognition for contributors
Build a "Wikipedia of customer personas"

2. Open Source Core Components

Release the Behavioral Economics Engine for academic research
Allow developers to build custom simulations
Enable integration with existing product management tools
Foster an ecosystem, not a walled garden

3. Educational Partnerships

Partner with entrepreneurship programs and universities
Provide free access for students and educators
Create curriculum modules on AI-assisted product validation
Sponsor student startup validation projects

Integration & Workflow

1. Meet Users Where They Work

Notion Integration: Embed validation directly in product docs
Figma Plugin: Validate designs before building
Slack Bot: Quick validation checks during brainstorming
Linear/Jira: Connect validation to development tickets

2. API for Developers

RESTful API for custom integrations
Webhook support for automation workflows
SDK for common languages (JavaScript, Python)
Documentation with examples and use cases

3. Export & Portability

Export all data in open formats (JSON, CSV, PDF)
No vendor lock-in—your data is yours
Import capability for switching from other tools

Looking Further: The LLM Evolution

1. Growing With AI Capabilities

Here's what excites me most: LLMs are improving faster than anyone predicted.

Six months ago, the behavioral simulation we have today would have been impossible. Six months from now? A year from now? I genuinely cannot imagine what will be possible.

What I do know:

Persona reasoning will deepen: More nuanced decision-making, better edge case handling
Cultural understanding will expand: Truly localized personas, not translated ones
Multi-modal analysis: Personas that can evaluate video demos, voice pitches, interactive prototypes
Predictive accuracy will increase: As models improve, so will our forecasting

I'm building Persona Theater not just for today's capabilities, but as a platform that grows with AI advancement. The architecture is designed to plug in better models as they emerge.

2. Comparative Studies

Academic research comparing AI persona predictions to real user research
Publish findings in product management and UX research communities
Contribute to the broader understanding of synthetic user research

3. Ethical AI Validation

Develop guidelines for responsible use of synthetic personas
Address potential biases in AI-generated feedback
Create transparency reports on model behavior

The North Star

Persona Theater should be like a spell-checker for product ideas.

Available to everyone
Instant feedback
Catches obvious mistakes before they become expensive
Doesn't replace human judgment—enhances it
Free for basic use, forever

I want the entrepreneur in Seoul, the student in São Paulo, and the first-time founder in Lagos to all have access to the same quality of initial product validation that well-funded startups take for granted.

This isn't about building a business. It's about leveling the playing field for ideas.

And as AI continues to evolve at breakneck speed, I'm genuinely excited to see where this journey leads. The validation capabilities we'll have in a year might be beyond anything I can currently imagine—and that's exactly why I'm building the foundation now.

Persona Theater: Validate Before You Build.

Making product validation accessible to everyone, everywhere.

Personal Development Goals

Refine my Kiro workflow: The steering files and hooks I created deserve more polish
Open-source my steering templates: Help other non-developers benefit from my learnings
Build a "Kiro for Non-Developers" guide: Document the patterns that worked

Long-term Mission

I believe no product should fail due to lack of market understanding.

My north star: Make product validation as accessible as spell-check. Any entrepreneur, anywhere, should be able to validate their idea in minutes, not months.

Persona Theater: Validate Before You Build.

Built With

Languages & Frameworks

TypeScript 5.7.3
React 18.3.1
Vite 5.4.19
Deno (Edge Functions runtime)

UI & Design

Tailwind CSS 3.4.1
shadcn/ui (Radix UI primitives) - customized, never default
Framer Motion 11.15.0
Lucide React (icons)

State Management

Zustand 5.0.2
TanStack Query 5.66.1
Zod 3.24.1 (validation)

Backend & Cloud

Supabase (Database, Auth, Edge Functions)
Upstash Redis (Serverless caching)
Vercel / Cloudflare (Hosting)

AI & APIs

Google Gemini 2.5 Flash
Brave Search Pro AI
Custom D-CoT implementation

Internationalization

i18next 24.1.0
react-i18next 14.1.3

Development Tools

Kiro (AI-powered IDE with specs, steering, hooks, powers)
13 MCPs: Serena, Memory, Brave, Exa, Ref, Context7, Supabase, Shadcn, Chrome DevTools, Firecrawl, Sequential Thinking, and more
ESLint + Prettier (code quality)
Git + GitHub (version control)

Repository Structure

persona-theater/
├── .kiro/                    # Kiro configuration
│   ├── specs/                # 21 specification documents
│   ├── steering/             # 14 AI guidance files
│   │   ├── korean-language-response.md
│   │   ├── no-assumptions-enforcement.md
│   │   ├── atomic-development-principles.md
│   │   ├── task-execution-mindset.md
│   │   ├── tasks-format.md
│   │   ├── ears-requirements.md
│   │   ├── spec-pbt-correctness.md
│   │   └── ...
│   ├── hooks/                # 4 agent automation hooks
│   │   ├── spec-generation-hook.md
│   │   ├── task-execution-hook.md
│   │   └── ...
│   └── settings/             # MCP configuration
├── src/
│   ├── features/             # Feature modules
│   │   └── e2e-orchestration/# 10-stage pipeline
│   ├── components/           # React components (Presentation)
│   ├── lib/                  # Core business logic
│   │   ├── behavioralEconomics.ts
│   │   ├── dynamicCoT.ts
│   │   ├── personaGenerator.ts
│   │   └── simulationEngine.ts
│   ├── stores/               # Zustand stores
│   └── services/             # API clients
├── supabase/
│   └── functions/            # 16 Edge Functions
└── public/                   # Static assets

My Kiro Configuration Highlights

Steering Files Overview

File	Purpose	Inclusion
`task-execution-mindset.md`	MCP workflow enforcement	Always
`no-assumptions-enforcement.md`	Fact/Solution/Question pattern	Always
`atomic-development-principles.md`	One item at a time	Always
`korean-language-response.md`	Korean UI/UX responses	Always
`tasks-format.md`	Task format standards	File match: tasks.md
`ears-requirements.md`	EARS pattern enforcement	Manual
`spec-pbt-correctness.md`	PBT generation guide	Manual
`frontend-design.md`	Anti-AI aesthetics	File match: *.tsx

Hook Examples

Spec Generation Hook (Manual):

Execute modular design:
1. Analyze requirements → User/Data flow
2. Explore codebase → Conventions
3. Design modules → Presentation/Business Logic separation

Output: Overview, Mermaid Diagram, Implementation Plan

Task Execution Hook (Manual):

ALWAYS USE SERENA MCP ALL THE TOOLS ALL THE TIME!!
Research first (Brave, Exa, Ref) → Serena analysis → 
Sequential thinking → Memory save

About Me

Jinha

Role: Solo Founder / Non-Developer turned Builder
Background: 4 years as CEO of Leda Games, specializing in Webtoon based games
Experience:
- Successful crowdfunding (120 million won on Tumblbug)
- Pre-A investment from Kakao Games
- Partnerships with Naver and TVING
- Operated immersive game experience center in Hongdae
Current Focus: AI-powered product validation, transitioning to new ventures
Tech Journey: React, Next.js, TypeScript, Supabase—learned through building

Acknowledgments

Kiro Team for building an incredible spec-driven IDE that made this possible for a non-developer
Anthropic for Claude's reasoning capabilities
Google for Gemini 2.5 Flash
Brave for Pro AI search APIs
Kahneman & Tversky for behavioral economics foundations
The AI Business Course community for support during this journey

A Personal Note

Three weeks ago, I wasn't sure I could build this. As a non-developer who's spent 7 years creating analog experiences—murder mysteries, escape rooms, immersive games—the idea of shipping a 73,000-line TypeScript application felt impossible.

But Kiro changed that equation. By forcing me to think in specs, to separate presentation from logic, to research before coding, to never assume—it transformed my entrepreneurial instincts into working software.

This hackathon wasn't just about building Persona Theater. It was about discovering a new way to create. The process of learning a new feature, adding a steering file, testing an MCP workflow—each day brought genuine joy.

To other non-developers reading this: It's possible. The gap between vision and implementation is smaller than you think. You don't need to become a developer. You need to become systematic.

To the Kiro team: Thank you for building something that includes people like me.

Persona Theater: Don't Build What Nobody Wants.

Validate in minutes. Build with confidence.

— Built by a non-developer who learned that specs are superpowers.

Built with ## Built With

Languages & Frameworks

Technology	Version	Purpose
TypeScript	5.7.3	Primary language with comprehensive type coverage
React	18.3.1	UI library
Vite	5.4.19	Build tool for blazing-fast development
Deno	Latest	Edge Functions runtime

UI & Design

Technology	Purpose
Tailwind CSS 3.4.1	Utility-first styling
shadcn/ui	Radix UI primitives (customized, never default)
Framer Motion 11.15.0	Smooth animations and micro-interactions
Lucide React	Icon library
Neo-brutalism Design System	Custom aesthetic direction

State Management & Data

Technology	Version	Purpose
Zustand	5.0.2	9 specialized stores for state management
TanStack Query	5.66.1	Server state and caching
Zod	3.24.1	Runtime validation and type inference

Backend & Cloud

Technology	Purpose
Supabase	Database, Auth, Edge Functions (16+ functions)
Upstash Redis	Serverless caching
Vercel / Cloudflare	Hosting and CDN
Deno Deploy	Edge function deployment

AI & APIs

Technology	Purpose
Google Gemini 2.0 Flash	Primary LLM for persona simulation
Brave Search Pro AI	Real-time market research
Custom D-CoT Implementation	Dynamic Chain-of-Thought for adaptive reasoning
Behavioral Economics Engine v6.0	Kahneman & Tversky loss aversion model

Internationalization

Technology	Version	Purpose
i18next	24.1.0	Core i18n framework
react-i18next	14.1.3	React bindings
20+ namespaces	-	English + Korean full support

Development Environment: Kiro IDE

The heart of this project's development process.

Component	Count	Details
Specs	21	Full requirements → design → tasks cycles
Steering Files	14	Manual, conditional, and always-active guidance
Hooks	4	Spec generation, task execution, validation, deployment
Powers	5	Research, Code, Design, Thinking, Testing

MCP (Model Context Protocol) Integrations

13 MCPs orchestrated in a Compounding Engineering workflow:

MCP	Primary Use
Serena	Symbol-level code analysis and editing
Memory	Cross-session learning accumulation
Brave Search	Pro AI-level web research
Exa	Deep research, code context, web search
Ref	Official documentation lookup
Context7	Library documentation
Supabase	Database operations and Edge Function deployment
Shadcn	UI component integration
Chrome DevTools	Browser verification and testing
Firecrawl	Web scraping and content extraction
Sequential Thinking	Step-by-step reasoning
GitHub	Repository operations
Filesystem	File operations

Kiro Powers Configuration

Power	MCPs Combined	Purpose
Research Power	Brave + Exa + Ref + Firecrawl	Best practices and documentation lookup
Code Implementation Power	Serena + Context7 + Filesystem	Symbol-level development
Design Power	Shadcn + Frontend steering	UI component work
Thinking Power	Sequential Thinking + Memory	Complex problem solving
Testing Power	Chrome DevTools + Supabase	Verification and deployment

Custom Steering Files

File	Inclusion Type	Purpose
`task-execution-mindset.md`	Always	MCP workflow enforcement
`no-assumptions-enforcement.md`	Always	Fact/Solution/Question pattern
`atomic-development-principles.md`	Always	One item at a time
`korean-language-response.md`	Always	Korean UI/UX responses
`tasks-format.md`	File match	Task format standards
`ears-requirements.md`	Manual	EARS pattern enforcement
`spec-pbt-correctness.md`	Manual	Property-Based Testing guide
`frontend-design.md`	File match	Anti-AI aesthetics
`spec-quality-standards.md`	File match	Spec document standards
`step-by-step.md`	Manual	3-phase development process
`clean-code.md`	Always	Code quality standards
`development-best-practices.md`	Always	General guidelines

Custom Hooks

Hook	Trigger	Purpose
Spec Generation Hook	Manual	Enforce modular design with Presentation/Business Logic separation
Task Execution Hook	Manual	MCP workflow with mandatory research-first approach
Phase Validation Hook	Manual	End-of-phase verification and bug fixing
Deployment Hook	Manual	Supabase Edge Function deployment

Code Quality Tools

Tool	Purpose
ESLint	Code linting
Prettier	Code formatting
TypeScript Strict Mode	Type safety
Property-Based Testing (fast-check)	Correctness verification

Version Control

Tool	Purpose
Git	Version control
GitHub	Repository hosting
Conventional Commits	Commit message standards (Korean)

Architecture Principles Enforced

Principle	Implementation
Presentation / Business Logic Separation	Mandatory in all specs
Atomic Development	One item at a time, always compilable
EARS Requirements	All acceptance criteria follow EARS patterns
Property-Based Testing	Correctness properties in design.md
No Assumptions Policy	Fact → Solution → Question pattern
Test Before Integration	Isolated test pages before merging
Compounding Engineering	Memory MCP saves learnings across sessions

Total Lines of Code: ~73,000 lines of production TypeScript

Development Period: 3 weeks

Development Mode Split: 50% Spec Mode / 50% Vibe Mode

Built With

api
brave
chrome
cloudflare
context7
css
deno
devtools
edge
eslint
exa
flash
framer
functions
gemini
git
google
i18next
ide
kiro
lucide
mcp
memory
motion
prettier
query
react
redis
search
serena
shadcn/ui
supabase
tailwind
tanstack
typescript
upstash
vercel
vite
zod
zustand