Building a fast, throwaway prototype to validate an idea before a production build. This uses Salesforce low-code tools in an isolated environment, with the goal of answering one question and gathering feedback.
- Write down the question
State the single thing this prototype must answer, such as whether users understand a screen or whether a flow matches the real process. The question sets the fidelity and tells you when you are done.
- Pick a safe environment
Spin up a scratch org for a quick disposable build, or use a sandbox when the prototype needs to feel like your real org. Never prototype in production.
- Build the smallest version that works
Use Lightning App Builder to assemble screens and Flow Builder to draft automation. For an agent, stand up a draft Agentforce agent. Build only enough to answer the question.
- Test it with real users
Give a few intended users a realistic task and watch without coaching them. Note where they hesitate or go wrong, and capture the feedback.
- Decide, then throw it away
Turn the findings into a decision about the design. Discard the prototype and rebuild the feature properly for production rather than promoting the experiment.
How real the prototype feels. Start low-fidelity for idea testing; raise it only when you need believable usability feedback.
Scratch org for short-lived, source-driven experiments; sandbox when the prototype must mirror existing configuration and data shape.
Choose ideation, exploration, or validation up front. The purpose decides how much effort and polish the build deserves.
- A prototype that looks finished tends to become the production system by accident. Be explicit that it is disposable.
- Over-polishing a throwaway build wastes the speed that made prototyping worth doing. Stop once the question is answered.
- Prototyping in production risks live data and real users. Always isolate the work in a scratch org or sandbox.
- Skipping the user test turns a prototype into guesswork. The feedback is the whole point of building one.