A screenshot is a promise you took once and hoped stayed true. We got tired of the promise drifting, so we deleted the screenshots and made the product page render the actual software.
If you open our products page, nothing on it is an image. The pipelines move. An invoice gets marked paid. The AI agent answers a question and the typing indicator blinks. It is all live DOM and CSS, rendered on the fly, on every visit — thirteen systems, one engine.
Why screenshots quietly rot
Marketing screenshots have three problems that compound over time. They go stale the moment the product changes. They are heavy — a handful of retina PNGs can outweigh the entire rest of a page. And they are dishonest in a small way: they show a frozen best-case, never the thing moving.
- Staleness — the product ships weekly; the screenshot was taken in March.
- Weight — five 2x PNGs can be 4–8 MB; the page they sell is 200 KB.
- Flatness — software is motion, and a still frame throws the motion away.
The architecture
Each product demo is a self-contained React component with its own little state machine. There is no backend call, no real data — it is a choreography. A shared useScene hook drives a deterministic timeline, and every system plugs into it.
// one scene, many beats — deterministic and reduced-motion aware
function useScene(beats: number, ms = 2200) {
const [beat, setBeat] = useState(0);
useEffect(() => {
if (matchMedia('(prefers-reduced-motion: reduce)').matches) return;
const id = setInterval(() => setBeat((b) => (b + 1) % beats), ms);
return () => clearInterval(id);
}, [beats, ms]);
return beat;
}The trick is that the layout is the real product layout, lifted straight from the live build and frozen as a presentational shell. So when the product changes, the demo is one import away from changing with it.
Reduced motion is not optional
Anything that animates forever has to respect prefers-reduced-motion. Every scene checks the media query and, if motion is reduced, renders the final beat statically. The page still tells the whole story — it just stops moving for people who asked it to.
What it bought us
Beyond weight and honesty, there is a sales effect we did not expect: a moving interface reads as built. A static one reads as designed. For a studio that ships working software, that difference is the entire pitch.
Show the thing running, or you are just showing a picture of a promise.
— Studio principle
Would we do it again
- For a product studio selling working systems — yes, without hesitation.
- For a brochure site that changes twice a year — no, a screenshot is fine.
- The deciding question: does motion prove something a still cannot? If yes, build it live.
Want your product page to run the real thing instead of a picture of it?
Start a projectQuestions, answered
- Does live software hurt page performance?
- Done right it helps — there are no image downloads, and CSS transforms run on the compositor. The risk is animating layout properties; we only animate transform and opacity.
- How do you keep the demos in sync with the real product?
- Each demo reuses the product's real layout as a presentational shell, so a product change is one import away from updating the demo.
The stack we actually use
The tools below run our own systems and the ones we build for clients. A few are affiliate links — they support The Signal at no cost to you.
Some links on this site are affiliate links. If you click through and sign up or buy, J Supreme Tech may earn a commission at no extra cost to you. We only recommend tools we actually use to build and run our own systems. Full disclosure.