Build and test a product prototype with a coding assistant
Use a coding assistant to explore a product extension before committing a full development team.
How this works
Use a coding assistant to explore a product extension before committing a full development team. Use this to explore a narrow product extension before committing a larger engineering effort. The prototype should answer a concrete feasibility or usability question while making its simulated and incomplete parts explicit.
Define a small user journey, implement it locally with a coding assistant, and test it with the internal team. Prefer existing project tools and a file-based fallback over unnecessary services. Engineering reviews the prototype's reliability, permissions and maintainability before any release decision.
Before you start
Prototype brief
State the user, problem, core journey and exclusions.
Existing project context
Inspect relevant conventions and available development tools.
Safe test data
Use synthetic records and isolated accounts for the experiment.
Prepare the inputs
- feature_scope
- Required
one bounded product outcome
Exclude unrelated roadmap ideas.
- sample_inputs
- Required
representative normal and edge cases
Avoid live customer data unless explicitly necessary and permitted.
- technical_context
- Required
repository, stack and current constraints
Do not invent dependencies or platform support.
- review_criteria
- Required
feasibility questions and observable behavior
Separate prototype success from production readiness.
Implementation, step by step
Define the smallest useful version
- Describe the end-to-end task the prototype must demonstrate.
- List simulated integrations and omitted production concerns.
Checkpoint: The experiment has a bounded scope.
Prepare the workspace
- Use an isolated working context and inspect existing conventions.
- Confirm the app can run before adding the feature.
Checkpoint: The baseline is known.
Build the prototype
- Implement the core journey with the available coding assistant and tools.
- Keep changes focused and preserve clear error handling for expected bad inputs.
Checkpoint: A runnable local artifact exists.
Exercise with the team
- Run realistic tasks and relevant edge cases using the sample data.
- Record observed behavior and feedback separately from enthusiasm or preferences.
Checkpoint: The prototype answers its initial questions.
Prepare engineering handoff
- Summarize changed files, tests, limitations and production work still needed.
- Keep release authorization separate from internal acceptance.
Checkpoint: Engineering can decide what to retain.
Decisions along the way
External integration is unavailable
Simulate it explicitly and do not claim end-to-end integration.
Prototype reveals a different problem
Record the learning and ask the owner to choose the next scope.
New dependency is unnecessary
Use the existing stack or a simple local fallback.
What you will produce
product-prototype
Local app or code patchA bounded artifact for internal testing.
Include: core_flow · sample_data · simulations · limitations
prototype-handoff.md
MarkdownA concrete engineering review packet.
Include: questions · observations · tests · risks · next_steps
Check the result
- Run the actual prototype through its core journey.
- Test representative invalid and empty inputs.
- Inspect the diff for unrelated changes.
- Confirm simulated behavior is labeled in the handoff.
When something goes wrong
Build fails
Preserve the error and resolve the bounded issue before claiming a working prototype.
Prototype corrupts test data
Stop, restore the isolated dataset and fix the write path.
Internal feedback exceeds scope
Record ideas separately rather than adding them automatically.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Synthetic: prototype a document-to-checklist feature.
Inputs
Scope is one uploaded text file, editable extracted actions and local save. Team sample includes an action with no deadline.
Expected result
Synthetic result: show the editable checklist with deadline unknown and save it locally. Label cloud sync and team permissions as unimplemented rather than pretending they work.
Run a small pilot
Start small
Use one core journey with a small internal review group.
Record the baseline
Record build effort, failed flows and questions answered.
Agree success criteria
Agree feasibility and observable-behavior criteria before further investment.
Stop or revise
Stop expansion if the prototype cannot be isolated or its core flow remains unreliable.
Keep the scope clear
- Internal testing is not evidence of production readiness.
- Do not deploy or connect real customer systems merely because the prototype runs.
Check before using
Check reliability, permissions, security, and maintainability; internal testing is not proof of production readiness.
Business activities
- Plan products and business changes
- Build and change software
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Product requirements · Platform constraints · Internal tester feedback
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow