Protodev: A Prototype-Driven Development Process

Overview#

Protodev is a development process that leverages AI-assisted rapid prototyping to compress discovery cycles and improve stakeholder collaboration. Instead of describing what software should do, we show it. Instead of estimating based on assumptions, we validate through working prototypes.

The core insight is simple: when building a prototype takes hours instead of weeks, the economics of feedback change fundamentally. We can afford to show before we tell, to validate before we commit, and to iterate before we invest.

Requirements for Protodev#

Protodev depends on specific capabilities. Without these, the process will not deliver its intended benefits.

AI-Assisted Development#

The team must have access to AI development tools capable of generating functional prototypes rapidly. This includes tools like Claude Code or similar AI coding assistants. The goal is to produce working software in hours, not days or weeks.

• Prototypes should be achievable in under 2 hours for typical feature scope
• Iterations based on feedback should be achievable in minutes
• Team members should be trained and comfortable with AI-assisted development workflows

Prototype Sharing Mechanism#

Stakeholders must be able to interact with prototypes easily. This requires a deployment or sharing mechanism that allows non-technical stakeholders to experience the prototype without setup or installation.

• Prototypes should be accessible via URL or simple sharing link
• Stakeholders should be able to click through and interact, not just view screenshots
• Updates to prototypes should be deployable quickly to enable real-time feedback sessions

Feedback Capture Process#

There must be a clear process for gathering, documenting, and acting on stakeholder feedback. This can be synchronous (live demo sessions) or asynchronous (recorded feedback), but it must be structured enough to inform development decisions.

Kanban Board#

Work is tracked using a kanban-style board rather than sprint-based planning. The board should support tracking work from prototype through production, with clear visibility into what is in progress, what is ready to build, and what has been completed.

The Process#

Protodev consists of three phases: Pre-Development, Project Kickoff, and Ongoing Development. Each phase has distinct activities and goals.

Phase 1: Pre-Development (Sales & Discovery)#

This phase occurs before any contract is signed. The goal is to validate understanding and build stakeholder confidence through a working prototype.

Step 1: Initial Client Conversation

Meet with the prospective client to understand their needs, goals, and constraints. Focus on understanding the problem they are trying to solve, who will use the system, and what success looks like. Take notes, but do not commit to scope or approach yet.

Step 2: Discovery Prototype

Using AI-assisted development, create a functional prototype that demonstrates the core concepts discussed. This prototype should be built quickly (typically within hours of the initial conversation) and should be good enough to elicit meaningful feedback, not production-ready.

The prototype is disposable. Its purpose is to make abstract discussions concrete and to validate understanding before significant investment.

Step 3: Prototype Demo & Feedback

Schedule a session with the client to walk through the prototype. Encourage them to interact with it directly. Capture their reactions, corrections, and new ideas. Iterate on the prototype in real-time if changes are small, or note larger changes for follow-up.

This step may repeat multiple times until the prototype reflects a shared understanding of what will be built.

Step 4: Scope of Work & Estimate

With a validated prototype in hand, produce a Scope of Work document and technical estimate. The prototype serves as a concrete reference for what is being scoped, reducing ambiguity and misalignment.

Step 5: Proposal & Contract

Present the proposal to the client. Because they have already seen and provided feedback on a working prototype, the conversation focuses on timeline and cost rather than whether you understand their needs.

Phase 2: Project Kickoff#

This phase transitions from the discovery prototype to production development. The goal is to establish the production system foundation while using the prototype as a reference.

Step 1: Production System Setup

Set up the production codebase, infrastructure, and deployment pipeline. This is built from scratch with proper foundations: appropriate architecture, authentication, database design, testing infrastructure, and CI/CD. The prototype is a reference, not a starting point.

Step 2: Feature Transfer

Systematically implement features from the prototype into the production system. Use the prototype to understand what each feature should look like and how it should behave. Create cards on the kanban board for each feature, linking to the relevant parts of the prototype.

Step 3: Stakeholder Transition

Once the production system reaches feature parity with the prototype, transition stakeholders to reviewing the production system directly. The prototype has served its purpose and can be retired.

Phase 3: Ongoing Development#

This phase covers continued development after the initial build. Work flows continuously rather than in time-boxed sprints.

Feature Development

When new features are requested, the same prototype-driven approach applies:

1. Create a mini-prototype demonstrating the proposed feature
2. Review with stakeholders, gather feedback, iterate as needed
3. Once approved, create a card linking to the mini-prototype
4. Build the feature properly in the production system

Mini-prototypes should be small and focused on specific features. If a mini-prototype starts to feel like a whole new system, it is too big.

Technical Work

Hardening, integration, performance optimization, and maintainability work runs parallel to feature development. These tasks are driven by engineering judgment rather than stakeholder feedback loops. They are tracked on the same kanban board but do not require prototype validation.

Demos

Conduct demos of completed work for stakeholders on a regular cadence, typically every one to three weeks depending on the project and team. This is not a planning gate; it is a visibility checkpoint. Work completed since the last demo is presented. Stakeholders can see progress against the overall scope and raise concerns or new priorities.

To track what is ready for demo, use either a date-based filter on completed items or a dedicated column on the kanban board for work awaiting demo.

Work Tracking#

Kanban Board Structure#

Work is tracked on a kanban board with the following columns:

Card Contents#

Cards should be lean. The prototype is the spec. Each card should include:

• Title: Clear enough to identify the work at a glance
• Link to prototype: Or screenshot/video if the prototype may change
• Production context: Where in the system does this live
• Acceptance criteria: What must be true for this to be done (brief bullets)
• Stakeholder notes: Specific feedback or decisions from prototype review
• Technical considerations: Only if non-obvious constraints exist

A developer should be able to pick up the card, review the prototype, read the acceptance criteria, and begin work without requiring a meeting.

Card Sizing#

With AI-assisted development and clear prototype references, larger cards are often appropriate. The heuristic: if one person can complete the work and get it reviewed within a week, keep it as one card. Split cards when work will take longer than a week, multiple people need to work simultaneously, or parts can be demoed independently.

WIP Limits#

Without sprint boundaries, there is risk of everything being partially done. Enforce WIP limits on the In Progress column to maintain flow discipline. New work cannot start until current work finishes.

Principles#

These principles guide decision-making within Protodev.

Show, don't describe#

Stakeholders react to working software, not documents or wireframes. When there is a question about how something should work, build a prototype rather than writing a specification.

Prototypes are disposable#

Prototypes exist to inform decisions and validate understanding. They are not production code. Build them fast, get feedback, and throw them away. Never let a prototype become the foundation of a production system.

Feedback loops should be hours, not weeks#

The value of Protodev comes from speed. If prototypes take days to build or feedback takes weeks to gather, the process loses its advantage. Invest in the tooling and practices that keep feedback loops tight.

Flow continuously#

Work flows based on readiness and priority, not artificial time boundaries. Batch only for visibility (demos), not for planning. Sprint ceremonies are replaced by continuous delivery and regular stakeholder access to the production system.

Technical excellence runs parallel#

Do not wait for stakeholder permission to build things right. Security, performance, testing, and maintainability are engineering responsibilities that run alongside feature development. They do not require prototype validation.

What Protodev Replaces#

Protodev is designed as an alternative to sprint-based methodologies like Scrum. The following traditional practices are replaced or eliminated:

Roles and Skills#

Prototyping as a Core Skill#

Rapid prototyping with AI assistance should be developed as a skill across the team. While some team members may specialize, everyone involved in development should be comfortable creating prototypes. This includes developers and experience designers.

Developer Responsibilities#

• Create discovery prototypes and mini-prototypes as needed
• Build production features using prototypes as reference
• Maintain technical quality: testing, security, performance
• Participate in feedback sessions with stakeholders

Experience Designer Responsibilities#

• Create functional prototypes (not just static mockups) when possible
• Define look and feel through working examples
• Participate in stakeholder feedback sessions
• Describe behavior, not just appearance

Standardizing the Approach#

Teams should develop a consistent pattern for prototyping:

• Standard tools and stack for prototypes
• Clear definition of what is out of scope for a prototype (auth, real data, error handling)
• Standard sharing mechanism for stakeholder review
• Naming and organization conventions
• Clear triggers for when to stop iterating a prototype and build for real

Summary#

Protodev leverages AI-assisted development to compress feedback loops and improve stakeholder collaboration. By showing working software instead of describing it, teams validate understanding before committing to production development. Work flows continuously using kanban, with regular demos providing visibility without the overhead of sprint ceremonies.

The process requires AI-assisted development capability, a mechanism for sharing prototypes with stakeholders, and a kanban board for tracking work. Teams adopting Protodev should invest in developing prototyping as a core skill across developers and designers.

Protodev is not a rejection of Agile principles. It is a fulfillment of them in a world where building is fast enough to make showing cheaper than telling.