Start from the decision, not the feature list
Before requesting work, clarify what the prototype must prove. Feel, pacing, screen flow, and tuning range are better starting points than a broad feature list.
- Decision needed for the next step
- Where placeholder assets are acceptable
- What will not be built this time
Decide how review builds will be used
A prototype is more useful when the review method is clear. Decide who will play it, what device or input method is needed, and which parameters should be adjustable.
Assume some work will be discarded
Prototype code is not always production code. Separate what should remain, what should be rebuilt, and what should be discarded.
Common Inquiry Examples
Unity prototype inquiries often start from a need to create evidence before committing to full production.
- Test only a new interaction feel
- Judge whether a concept is fun beyond the document
- Decide what to cut before full development
What to Decide Before Requesting Work
Before broadening the scope, define the decision this prototype must support and where rough assets are acceptable.
- Interaction or pacing to validate
- Screens and effects that can use placeholders
- Who reviews builds and how often
Patterns That Often Fail
A prototype becomes heavy when it tries to look like a finished product before the core question is answered.
- Aiming for production quality from the start
- No agreement on placeholder asset scope
- No clear reviewer or review cadence
How Nobilwing Can Support
Nobilwing can build a small playable prototype and connect the review result to the next development decision.
- Unity review builds
- Validation items and tuning parameters
- Implementation notes and next-phase options
Before Inquiry
- Narrow the validation questions to one to three
- Decide where placeholder assets are acceptable
- Choose target devices and input methods
- Decide review build frequency
- Define what qualifies for full development