You don't have a testing team. You're the whole team. A sandbox is your rehearsal space.
You don't have a testing team. You don't have a QA department. You don't have a staging environment managed by DevOps. You're the whole team.
A sandbox is where you break things safely so your real product never breaks in front of real people.
RESTAURANT: A sandbox is your test kitchen. You try new recipes here. You experiment with plating. You make mistakes. None of it goes to the dining room until you're confident it works. If you're cooking experiments on the live line, one bad night closes the restaurant.
You need two copies of your development environment:
Production — What your real users see. Real data, real payments, real consequences. You deploy here only when you're confident something works.
Sandbox — Your playground. Same code structure, same database schema, but connected to test accounts and test data. This is where every new feature gets built and tested first.
The folder structure is simple: ~/ProjectFluency is production. ~/ProjectFluency2 is sandbox. Same codebase, different environment variables pointing to different services.
DEF: Environment variables — Configuration values that change between environments. Your sandbox points to test API keys, test payment accounts, and test databases. Your production points to the real ones. Same code, different configuration.
Every change follows the same path:
1. Build in sandbox. Write the code, test it, break it, fix it.
2. Test with real scenarios. Not "does it compile" — does it handle the weird edge cases your users will actually hit?
3. Promote to production. Copy the tested code to your production environment. Deploy. Monitor.
Never skip step 2. The most expensive bugs are the ones that work perfectly in isolation but fail when they interact with real user behavior.
NOTE: Your sandbox edge functions should use a naming convention that makes them impossible to confuse with production. I append -sandbox to every sandbox function name. When you're deploying at midnight, you do not want to deploy the wrong version.This is where GitHub branches (Chapter 3) become essential. Your sandbox work lives on a feature branch. When it's tested and ready, you merge it to main and deploy to production. If something goes wrong, you revert the merge. Your production code is never more than one git command away from the last known good state.