Test on the real thing: why we verify on the live preview, not a laptop
The worst deploy we have made came from a laptop that was a few weeks behind. The code looked right, the tests passed locally, and an old version of an email feature overwrote the correct one in production.
We no longer trust a laptop as proof that software works. Every change is deployed to its own live preview address, checked there on real devices with real accounts, merged only after that check, and then confirmed on production. The laptop is where code is written; the preview is where it is believed. It makes fixes faster, not slower, because there is nothing to set up and nothing to argue about.
What "works on my machine" was costing us
A developer's laptop is a private copy of the world. It has its own version of the database, its own saved logins, its own leftover settings from last month's experiment. Code that runs there is running against a reality nobody else shares. The classic result is the phrase every owner has heard: it works on my machine.
Our own version of that story involved a stale checkout. A coding tool was working from a copy of the project that had fallen behind the live one, rebuilt a notification feature that had already been rewritten, and shipped the old approach over the new one. It was caught and reverted the same session, but it changed a rule: nothing is verified locally anymore.
What a preview deployment is
Every change we make goes onto its own branch, a separate line of work that does not touch the live site. The hosting service builds that branch automatically and gives it a real web address. That is a preview deployment: the actual app, on the actual hosting, with the actual settings, at a link anyone can open on their phone. It is not the live site, and it is not a laptop. It is a true rehearsal.
The loop, every time
- The change is written, usually by an AI coding tool following a rules file in the project.
- It is pushed to a branch and the hosting builds a preview.
- We open the preview on a phone and a desktop, log in with a real test account, and run the exact thing that changed: submit the form, score the lead, send the alert.
- Anything that touches another user's data gets checked with two accounts, to prove one cannot see the other.
- Only then is the branch merged into the main line, which deploys to production.
- We open production and check the same thing once more, because a merge can still surprise you.
The rules file in each project says this in plain words: do not run the app locally; verify on the live preview; merge only after the check; confirm on production. The tools read it, and so do we.
Why this makes fixes faster, not slower
It sounds like extra ceremony. It is the opposite. There is no local environment to set up or keep in sync, so a fix can start the minute it is reported. The owner can open the preview link and say yes or no without a screen share. There is no argument about whether the bug is real, because the preview uses the same database rules and the same services as production. And when a client with one database and no separate staging system needs a change, the preview is the only honest rehearsal available.
A driver who reports a broken photo upload at the start of a shift can have the fix on the preview, checked, merged and live before the shift ends. That speed comes from removing the laptop from the chain, not from adding steps.
What a laptop is still for
- Writing the code and reading it.
- Running quick automated checks before pushing, as a first filter.
- Nothing that counts as proof.
What this means for an owner
When someone tells you a change is done, ask where they checked it. If the answer is a laptop, it is a draft. If the answer is a preview link you can open yourself, it is a change. You should be able to see every change before it goes live, from your own phone, without installing anything. That is what a preview deployment gives you, and it costs nothing extra once the project is set up for it.
Every system we run for clients, from a builder's CRM to a transit dispatch platform, ships through this same preview, merge and production loop, which is why a fix reported in the morning is usually live by the afternoon.
Questions people ask
What is a preview deployment in plain words?
It is a real copy of your app, built automatically from a proposed change, running on the real hosting at its own temporary web address. You can open it on your phone and try the change before it goes live. It is the rehearsal that a laptop can never be.
Does testing on a live preview risk the real data?
The preview runs against the same database rules as production, so we use test accounts and test records and never touch real customer data during a check. Where a client has only one database, that discipline matters more, and the check for data separation is done with two test accounts rather than real ones.
Why do you say not to trust tests that pass on a laptop?
Because a laptop has its own database, settings and leftovers that production does not have, so passing there proves only that it works in that private world. The preview uses the real settings and services. Local tests are a useful first filter; they are not the proof.
Want this done for your business?
Two minute intake. A real person reads every one and replies within a business day.
Keep reading
Vibe coding: what it is, what it is not, and what it means for your business
Vibe coding explained for owners: describing software in plain English and letting AI write it.
New softwareWe cloned a CRM for a new industry in a day. Here is how
How a CRM built for a home builder became a landscaping CRM and an advisor CRM in a day: what stayed, what changed, and why a proven core beats a blank page.
New softwareThe new age of software development: what changed and what did not
AI now writes most of the code in a software project.