How Two Developers Built a Game That Sold 1M Copies: The Complete Indie Development Blueprint

Two developers created Thronefall using unconventional software practices that would horrify enterprise engineers, yet achieved remarkable commercial success through rapid prototyping, strategic compromise, and understanding market dynamics.

Jonas Tyler's development approach reveals how indie game creation requires fundamentally different engineering priorities than traditional software development, emphasizing speed and iteration over code quality.

Key Takeaways

• Indie game development succeeds with practices that would fail in enterprise software: no unit tests, no code reviews, direct pushes to main branch
• Rapid prototyping involves building 1-2 day mini-games for months before committing to a final concept, testing both gameplay and market viability
• Success requires finding the overlap between personal interest and market demand, not just following passion or pure market research
• Two-person teams can achieve million-copy sales through clear role division and strategic use of third-party assets from Unity Asset Store
• Pathfinding algorithms like A* become significant technical challenges even in seemingly simple games, requiring specialized plugins and workarounds
• AI tools like ChatGPT provide substantial productivity gains for skeleton code generation and domain-specific learning in areas like shader programming
• Game development prioritizes user experience and rapid iteration over code maintainability, with "spaghetti code" being acceptable for small teams
• Steam remains the dominant platform for indie games, typically representing 90% of revenue even after porting to other platforms

Timeline Overview

• 00:00–18:30 — Technical Architecture and Development Environment: Unity engine setup, C# programming, asset store usage, and project structure explanation
• 18:30–35:45 — Code Quality and Engineering Practices: Discussion of "spaghetti code," absence of unit tests, debugging with print statements, and direct main branch commits
• 35:45–52:20 — Unity Workflow and Visual Development: Scene management, game objects, mono behaviors, and integration between visual editing and code
• 52:20–68:35 — Prototyping Philosophy and Process: Daily mini-game creation, gameplay vs visual prototyping phases, and concept iteration strategies
• 68:35–85:10 — Technical Challenges and Solutions: A* pathfinding implementation, unit collision systems, dynamic node graph updates, and performance optimization
• 85:10–101:25 — AI Tools and Development Acceleration: ChatGPT for skeleton code generation, shader code translation, and strategic tool usage
• 101:25–118:40 — Game Launch and Business Strategy: Steam launch process, platform porting, revenue sharing models, and market dynamics
• 118:40–135:00 — Indie Development Advice and Success Factors: Engine selection, scope management, market-passion balance, and team building strategies

The Enterprise Engineering Heresy: Why "Bad" Practices Work for Indie Games

Jonas's admission of using practices that would be condemned in enterprise software reveals fundamental differences between game development and traditional software engineering that challenge conventional wisdom about code quality.

• Deployment frequency vs code stability trade-offs: Unlike web services that deploy continuously to production, games ship infrequently with extensive pre-release testing, making traditional CI/CD practices less critical than rapid iteration during development
• Team size scaling limitations: Practices like code reviews and unit testing provide value primarily when coordination overhead exceeds implementation speed, but two-person teams can communicate directly and maintain context without formal processes
• User impact assessment differences: Game bugs typically affect individual player experience rather than system-wide failures, making the risk tolerance for "spaghetti code" higher when shipping timelines are constrained
• Technical debt accumulation patterns: Games have finite development cycles with clear endpoints, allowing teams to accept technical debt that would be unsustainable in continuously maintained software systems
• Context switching costs in creative work: Code review processes interrupt creative flow states that are essential for game design iteration, potentially reducing overall productivity despite improving code quality
• Success metrics misalignment: Enterprise software optimizes for maintainability and scalability, while indie games optimize for market launch speed and player experience, creating different engineering priority hierarchies

Rapid Prototyping as Product Development Philosophy: The Science of Creative Iteration

The practice of building daily mini-games for months represents a systematic approach to product discovery that differs markedly from traditional software development planning phases.

• Search space exploration methodology: Creating 1-2 day prototypes functions as a sampling strategy across the possibility space of game mechanics, similar to A/B testing but applied to fundamental product concepts rather than incremental features
• Minimum viable concept validation: Prototypes test core gameplay loops without graphics, UI, or polish, allowing rapid evaluation of fundamental game mechanics before committing significant development resources
• Parallel development risk mitigation: Building multiple prototypes simultaneously reduces dependency on single concept success, spreading risk across a portfolio of ideas rather than betting everything on one vision
• Market intuition development through iteration: Regular prototyping develops pattern recognition for what mechanics feel engaging, building design intuition that informs both creative and commercial decisions
• Separation of gameplay and visual development: Deliberately decoupling mechanics from aesthetics prevents visual appeal from masking poor gameplay, ensuring core systems are solid before adding production value
• Creative constraint as productivity tool: Fixed timeframes (1-2 days) force rapid decision-making and prevent over-engineering during exploration phases, maintaining velocity while exploring possibilities

The Market-Passion Convergence Problem: Strategic Compromise in Creative Work

Jonas's emphasis on finding overlap between personal interest and market viability highlights the central tension in creative entrepreneurship between artistic vision and commercial success.

• Passion project sustainability limitations: Pure passion projects often fail commercially because creator preferences may not align with broader market demand, leading to products that satisfy makers but not buyers
• Market research execution challenges: Identifying profitable market opportunities requires skills distinct from game development expertise, and pure market-driven development often produces soulless products that fail despite apparent demand
• Creative authenticity as competitive advantage: Games developed with genuine creator investment tend to have unique qualities that differentiate them from purely commercial products, suggesting authentic interest provides innovation advantages
• Iteration toward convergence strategy: The prototyping approach allows gradual movement toward market-passion overlap by testing creator interest alongside rough market validation, avoiding binary choices between art and commerce
• Creative constraints fostering innovation: Limiting scope to viable market segments can spark innovative solutions within constraints rather than limiting creativity, similar to how technical limitations often drive creative breakthroughs
• Long-term career sustainability considerations: Building games purely for market returns risks creative burnout, while building unmarketable passion projects risks financial unsustainability, making convergence a career longevity strategy

Technical Complexity Hidden Behind Simple Interfaces: The Pathfinding Challenge

The extensive discussion of A* pathfinding reveals how seemingly simple game mechanics often require sophisticated algorithms and specialized knowledge that casual players never notice.

• Algorithm implementation vs configuration trade-offs: Purchasing pathfinding plugins rather than building custom solutions represents strategic technical debt acceptance, trading implementation time for customization complexity and ongoing dependency management
• Dynamic environment pathfinding complications: Real-time node graph updates when players build structures creates computational challenges that scale poorly, requiring specialized optimization techniques that typical software engineers rarely encounter
• Multi-layer pathfinding system complexity: Supporting different unit types (player units, enemy units, flying units) with separate node graphs exponentially increases system complexity compared to single-layer implementations
• Performance optimization in creative constraints: Unit limits in strategy games often reflect technical performance boundaries rather than design choices, showing how computational limitations directly impact user experience design
• Third-party integration customization requirements: Even commercial pathfinding solutions require extensive customization for game-specific behaviors, making vendor selection as important as implementation quality
• Debugging complexity in real-time systems: Pathfinding bugs manifest as visible unit behavior problems that affect gameplay feel, requiring different debugging approaches than traditional software issues that appear as data or interface problems

AI Tools as Development Force Multipliers: Strategic Automation in Creative Work

Jonas's sophisticated use of ChatGPT for skeleton code generation and domain learning represents an evolved approach to AI assistance that maximizes benefits while avoiding common pitfalls.

• Skeleton code generation as architectural thinking: Using AI to fill implementation details while maintaining human control over system architecture combines automation benefits with design oversight, ensuring AI assists rather than replaces engineering judgment
• Domain translation capabilities for specialized knowledge: AI tools excel at explaining complex domains like shader programming to developers from other backgrounds, effectively functioning as tutoring systems for rapid skill acquisition
• Intentional usage vs ambient automation preferences: Choosing manual AI invocation over continuous assistance tools like Copilot maintains developer agency over when automation occurs, preventing dependency on automated suggestions during creative problem-solving
• Boilerplate elimination without architectural compromise: AI handles repetitive implementation tasks while preserving human decision-making for system design, optimizing the human-AI collaboration for creative work where architecture matters more than implementation speed
• Learning acceleration for unfamiliar domains: AI serves as an always-available expert in specialized areas like graphics programming, reducing the barrier to working across multiple technical disciplines in small teams
• Quality control through human oversight: The "hallucination" criticism misses the point when AI outputs are treated as starting points requiring human validation rather than final solutions, making accuracy problems manageable through proper workflow design

Steam-Centric Business Strategy: Platform Economics in Indie Gaming

The revenue concentration on Steam (90% of sales) reveals how platform economics shape indie game business strategy and development decisions.

• Platform dependency risks vs market reality: While concentrating 90% of revenue on a single platform creates business risk, the alternative platforms don't provide sufficient volume to justify equal development investment
• Porting economics as revenue optimization: Console porting through specialized companies represents a low-risk revenue diversification strategy that requires minimal developer time investment while accessing additional markets
• Revenue sharing models in platform partnerships: Third-party porting deals typically involve revenue sharing rather than fixed costs, aligning partner incentives with game success while reducing upfront investment requirements
• Market validation through Steam performance: Success on Steam provides social proof that enables porting deals and console platform partnerships, making Steam performance a gateway to broader market access
• Development platform optimization strategy: Focusing initial development on Steam allows optimization for the primary revenue source before adapting for secondary platforms with different technical requirements
• Launch timing and market dynamics: Jonas's observation that launch timing optimization efforts largely cancel out suggests focusing on product quality over market timing provides better returns for indie developers

Team Structure and Role Division: Scaling Creative Collaboration

The clear division between Jonas (gameplay programming) and Paul (UI/art) demonstrates how small teams can achieve large-scale results through strategic specialization.

• Complementary skill optimization vs generalist approaches: Specialization allows each team member to develop deep expertise in their domain while maintaining sufficient cross-over knowledge for effective collaboration
• UI development as underestimated complexity: Paul's focus on UI systems representing 40-50% of development work reveals how interface design and multi-platform input support create substantial technical challenges beyond core gameplay
• Communication overhead scaling with team size: Two-person teams can maintain context through direct communication without formal project management tools, but this advantage disappears rapidly as teams grow
• Creative decision-making authority distribution: Clear role boundaries prevent decision paralysis while ensuring someone takes ownership of each major system, avoiding the common problem of everything being everyone's responsibility
• Cross-functional validation through role separation: Having different people responsible for gameplay feel vs user experience provides natural quality checks, as Paul can evaluate Jonas's gameplay decisions from a player perspective
• Geographic proximity benefits for creative work: Working in the same country (Germany) while maintaining some independence allows for in-person collaboration when needed while preserving individual creative focus time

Common Questions

Q: Why don't indie game developers follow traditional software engineering practices like unit testing and code reviews?
A: Game development prioritizes rapid iteration and creativity over long-term maintainability, and small teams can coordinate effectively without formal processes that would slow development velocity.

Q: How long should the prototyping phase last for an indie game?
A: Jonas recommends scaling prototyping time proportionally to total development time - roughly 10% of the planned development duration, such as 2 months of prototyping for a 2-year game project.

Q: What's the most important factor for indie game commercial success?
A: Finding the overlap between what you want to make and what will sell in the market, rather than following pure passion or pure market research approaches.

Q: Which game engine should new indie developers choose?
A: Resist building custom engines and choose established options like Unity, Godot, or Unreal Engine to maximize development speed and focus on game design rather than technical infrastructure.

Q: How do two-person teams handle all the different aspects of game development?
A: Strategic use of third-party assets from platforms like Unity Asset Store, combined with clear role division and willingness to learn multiple skills like music composition and 3D modeling.

Jonas and Paul's success with Thronefall demonstrates that indie game development operates under fundamentally different constraints and success metrics than traditional software engineering. Their approach of rapid prototyping, strategic compromise between passion and market demand, and acceptance of technical debt in service of shipping speed offers valuable lessons for creative technology projects. The key insight is that context determines appropriate engineering practices - what works for distributed systems at scale may be counterproductive for creative work in small teams with different risk profiles and success criteria.

Practical Implications

• Question whether traditional software engineering practices apply to your specific context and team size before implementing them wholesale
• Develop rapid prototyping skills for validating ideas quickly rather than committing to long development cycles without market feedback
• Use AI tools strategically for skill acquisition and boilerplate generation while maintaining human control over architecture and creative decisions
• Consider the trade-offs between code quality and shipping velocity based on your project's maintenance requirements and team structure
• Build games that balance personal interest with market viability rather than pursuing pure passion projects or purely market-driven development
• Leverage third-party solutions and asset stores to focus development time on unique game mechanics rather than rebuilding common functionality
• Accept that successful creative projects may require different engineering approaches than traditional software development
• Understand platform economics and concentrate initial development efforts on primary revenue sources before expanding to secondary platforms
• Develop cross-functional skills or clear role division to handle the diverse requirements of game development with small teams