Check what actually reaches the production bundle
A source import is a clue; the emitted build is the evidence.
When the project growsAbout 2 min read
A useful prototype leaves traces
Sample stories and simulated services help a prototype become testable before a backend exists. Later, API services may replace that path while development examples still have a legitimate place in the repository.
The important question is which path the production build can reach. My Next Step uses API services for its production application and gates a local demo import behind development mode. The presence of fixture files alone does not establish that they are shipped.
Inspect the output and the reachable paths
Build using the intended production configuration. Inspect the emitted chunks, source or module reports and the network requests made by the running build. Tree shaking, build-time conditions and lazy loading affect what is included and when it is downloaded.
Look for active imports of prototype services and for fallback behaviour after a real request fails. A genuine failure should not silently become a fictional successful record. Conversely, a development-only fixture that is excluded from the build need not be moved merely to satisfy a directory rule.
Separate size from behaviour
Record a baseline before cleanup and compare emitted size, load paths and behaviour afterward. Initial download size and all lazy chunks combined are different measurements. A smaller bundle is not proof that a false-data fallback is gone.
Keep intentional demos clearly separated and labelled. I want to know both what the person downloads and what the application will show when its real service is unavailable.