Most fast-built apps have one environment, or a staging that shares production's database. The minimum separation worth having, why separate AWS accounts beat naming conventions, preview environments per pull request, and how to test with realistic data without copying customers' personal information.
Testing in production is fine until a test deletes customer data, sends a real email to every user, or charges real cards. Separation exists so that mistakes have somewhere harmless to happen.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Put staging and production in different AWS accounts under AWS Organizations, not different names in one account. Permissions, quotas, costs and blast radius separate cleanly, and a developer's staging credentials cannot touch production. It costs nothing extra, and infrastructure as code makes the accounts identical apart from size.
Never point staging at the production database, even read-only.
Do not copy production personal data into lower environments. Generate realistic fake data, or anonymize irreversibly.
Use sandbox modes of providers (Stripe test mode, email sandboxes) everywhere except production.
Make it hard to send real email or SMS from non-production: an allow-list of internal addresses.
A separate secret per environment for every provider.
Configuration in the environment, not in code branches.
Production deploys only from CI, with the same artifact that passed staging.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
Safe Deploys for a Small Team: Feature Flags, Canaries and a Rollback You Have Practised
Shipping often is safer than shipping rarely, if each change is small and easy to undo. How feature flags separate deploying code from releasing features, how canary and blue/green deploys limit the blast radius, and the rollback habits that make a bad deploy a five-minute event.
Read
Your App Has Users Now: The Internet Underneath It, on One Page
Building fast skips the parts of the internet that only matter once people depend on you: DNS, certificates, email authentication, caching, timeouts, backups and abuse. What happens between someone typing your domain and your database answering, what breaks at each step, and the order we would fix things in.
Read
As of October 26, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.