Environment Variable

Environment variables are the configuration values that allow the same code to run safely in dev, staging, and production by pointing it at the right services for each. They are simple named strings that the application reads at startup. DATABASE_URL in dev might be postgresql://localhost:5432/fake_db with silly seed data. In staging it becomes a realistic database with anonymized customer records. In production it is the real thing that powers the business. The same pattern applies to everything external. STRIPE_KEY, CLERK_SECRET, LAUNCHDARKLY_SDK, SEGMENT_WRITE_KEY, all of them get swapped out automatically by the platform. This is what the article means when it says every environment runs the same code but talks to different services. Without environment variables teams would need separate repositories or tons of if environment equals production code which is brittle and hard to maintain. In 2026 with preview deployments spinning up in seconds these variables are set at the project level in Vercel or Render so every branch gets the correct test configs automatically. Doppler or 1Password Connect sync them across services so nothing leaks into a GitHub PR.

An environment variable is not a design asset. It is not something you spec in your handoff document alongside spacing tokens. It is not code that gets reviewed line by line in Figma. It is not the same from one environment to the next and that is the entire point. It is not safe to hardcode in source files where a screenshot could expose a live key. It is not something to ignore when debugging why the UI works in a preview but throws 500 errors on staging. It is not the job of the designer to create or edit them but it is your job to know they exist so you stop wasting time on the wrong tab.

Here is a concrete example. During a 2025 project for a subscription tool the team had a new upgrade modal. In the engineer's localhost the STRIPE_SECRET_KEY variable was a test key from 2023 that no longer matched the current test products in Stripe. The modal looked broken because the prices would not load. Once they updated the variable in their local .env file it worked. The preview deployment used the shared staging variables so it pulled the current test prices and the modal looked like the Figma file. On staging we tested with a realistic user who had multiple subscriptions and saw that the modal needed adjustment for that edge case the seed data never produced. The production variable was the live one so any mistake there would have charged real cards. We used the preview to catch the price loading issue and staging to catch the multiple subscription layout shift. Without understanding the variables I might have thought the code was bad when it was just a stale test key in dev.

Another concrete example involves auth with Clerk. The CLERK_PUBLISHABLE_KEY variable in dev and staging lets the app use test mode accounts. You can create accounts with fake emails like test+1@clerk.com. In production the variable is the live one so those test accounts would not work and any accounts created would be real. This is why the article says you do not log in as a fake user in production. One time a designer was checking a flow in what they thought was staging but was actually a production preview that had the live variables set by mistake. They created several test users that turned out to be real users in the production Clerk dashboard. The team had to clean up the data later. That is the cost of not paying attention to which variables are active. A third example is analytics with Segment. The SEGMENT_WRITE_KEY in preview deployments sent events to a test workspace so we could verify tracking on new flows without junking real dashboards. In production the key was different and events fed the customer data pipeline. When events disappeared after a deploy we traced it to a missing variable in the production config not a bug in the code.

You should use your awareness of environment variables every time you are about to review code. Use it to choose the right environment for the right kind of feedback. Use it to ask precise questions like which Stripe key is active instead of why does this look weird. Use it to avoid the common mistakes like reporting a live bug from a stale CDN cache or sending a dev URL to a client or clicking through production to test one thing real quick. Do not use environment variables as an excuse to skip reviews. Do not use them without understanding the security implications. Do not assume they are set correctly without confirmation. Do not file a bug report without noting which environment and which variables were active. Do these things and you avoid every classic error in the paper and become the designer engineers actually want to ship with.

Environment variables are the silent guardians that let designers focus on craft while keeping real users safe from half baked ideas.