Name the purpose of the substitute.
A trial may use a fixed response instead of an external service, a public sample instead of private records, or a simple local component instead of a future platform integration. These substitutions can be appropriate when they preserve the behavior relevant to the question.
The first step is to write down what each substitute is replacing and why. A convenient choice should not become an invisible assumption about the real environment.
The substitute belongs in the method. It affects the interpretation of the result just as the chosen sample or configuration does.
Ask which behavior must be real.
Suppose a prototype is meant to establish whether an external source supplies a required field. Replacing that source with a fixed response containing the field removes the very uncertainty the trial was meant to examine. The resulting screen may work without providing evidence about the source.
If the question concerns a downstream transformation, a controlled source response may be entirely suitable. The distinction depends on the claim, not on whether mock data is generally good or bad.
List the parts of the path whose actual behavior is necessary to answer the question. Then identify which surrounding parts can be simplified without changing that purpose.
Include relevant inconvenient behavior.
A substitute that always returns a complete, well-formed response can make a prototype feel more reliable than the proposed dependency. If missing fields, unavailable results, or changed formats matter to the question, the trial should not erase them accidentally.
Choose the relevant exceptions deliberately. A narrow investigation does not need to simulate every possible failure, but it should preserve the conditions that could change the decision under review.
Record which conditions were represented and which were not. That account helps the next person understand whether the prototype needs another trial before a broader conclusion is reasonable.
Do not let presentation imply a stronger result.
A polished interface can make simulated behavior appear settled. Labels, setup notes, and a clear demonstration introduction can prevent reviewers from treating a fixed example as a functioning connection.
Distinguish the visible output from the claim it supports. A screen rendering a sample record demonstrates that rendering path; it does not automatically establish ingestion, permission, scale, or production operation.
The same care applies to reports. A diagram should indicate substitutes rather than drawing every box as if it were an examined live dependency.
Use the boundary to plan the next investigation.
After a focused trial, the remaining substitutes can help identify what still needs to be made real. That does not mean replacing every substitute immediately. Prioritize the uncertainty that matters to the next decision.
A useful prototype record explains the question, the real path, the simulated parts, the observation, and the limits of reuse. That record lets the work inform a later implementation without overstating what the original exercise established.