I've spent the better part of a year building demo environments for a living. Not prototypes, not MVPs, not production apps. Demos: software whose entire purpose is to be watched for eleven minutes by someone deciding whether to spend money.
It is a strange discipline. Most of what I learned as a frontend engineer over the previous decade applies, but the priorities invert in ways that took me months to internalize. Here is what actually transferred, what didn't, and what I got wrong.
The demo is a narrative, and the code serves it
The first demo I built was technically excellent and completely useless.
I had built a content modeling walkthrough with proper error boundaries, optimistic updates, a loading skeleton for every async boundary, and a genuinely nice type-safe API layer. During the run-through, the account executive stopped me forty seconds in and asked why we were looking at a spinner.
The answer was that I had built for a real network. But nobody in a demo cares about a real network. They care about the moment where the thing they were promised happens on screen. Every millisecond before that moment is a millisecond where attention leaks.
The reframe that helped: a demo is a story with a claim, and every screen either advances the claim or dilutes it. Loading states dilute. Empty states dilute. Error handling — which I still believe is the most underrated skill in frontend engineering — dilutes, because the error never comes.
This does not mean building carelessly. It means the quality bar moves from robustness under adverse conditions to legibility under observation. Those are different targets and they require different code.
Seed data is the product
I underestimated this for an embarrassingly long time.
In production apps, seed data is a development convenience. You write a script, it fills the database with user_1@example.com and Lorem Ipsum, and you get on with the real work. The data is scaffolding.
In a demo, the data is the demo. When a prospect in commercial real estate looks at a content dashboard, the difference between "Article Title 1" and "Q3 Leasing Trends: Suburban Office Absorption" is the difference between watching a tool and seeing their own job.
I now spend more time on seed data than on components. A realistic dataset needs:
Plausible volume. Three records looks like a toy. Three thousand looks like a database dump. Somewhere between forty and two hundred, depending on the entity, feels like a real workspace that a real team has been using for a real year.
Temporal spread. Everything created on the same day is a tell. Real data has a long tail — things from last week, things from eight months ago, one thing from 2019 nobody has touched.
Deliberate imperfection. A workspace where every field is filled and every image is present looks synthetic. One draft with no cover image, one entry with a slightly-too-long title that wraps, one archived item. These read as authenticity precisely because a designer would have removed them.
Names that sound like the industry. This is the highest-leverage detail and the cheapest to get right. Ten minutes reading a prospect's actual site gives you the vocabulary their team uses internally.
Fast beats correct, until it doesn't
The tension I still haven't fully resolved.
Demos have brutal timelines. A prospect meeting gets scheduled Thursday for the following Tuesday, the environment needs to reflect their brand and their content model, and there is no version of that where you architect carefully.
So you take on debt aggressively. Hardcode the thing. Skip the abstraction. Put the mock response in a JSON file next to the component. This is correct and I would do it again.
The failure mode is that demo environments do not die. They get forked. Someone on another team sees the commercial real estate demo, changes six strings, and now there are two. Then eight. Then the original has a bug and the bug is in all of them.
What I settled on: debt is fine inside a demo, but never in the substrate. The theming layer, the seed data generator, the deployment pipeline — those get real engineering, because every future demo inherits them. The narrative-specific code on top can be as disposable as it needs to be.
The line is not "how important is this code" but "how many future demos will touch this code."
Theming is where the actual engineering lives
The most interesting technical problem in this job is making one codebase convincingly wear another company's identity.
Naively this is a color swap. In practice, brands differ along dimensions that break layouts in ways color never does. Type scale — a brand with a 72px display heading and a brand with a 32px one need different vertical rhythm, not a different font size. Border radius — a fully-rounded brand and a sharp-cornered brand imply different densities, different button padding, different card spacing. Logo aspect ratio, which quietly dictates header height and therefore every above-the-fold decision on the page.
Once I stopped treating theming as a palette problem and started treating it as a constraint-propagation problem, the whole thing got tractable. Design tokens with derived values rather than fixed ones. Spacing that scales from a type ratio. Component padding expressed as a function of border radius rather than a magic number.
This is the part of demo engineering that is genuinely just good frontend architecture, and it's the part I'd point to if someone asked whether this role keeps you sharp.
What transferred and what didn't
Transferred: component architecture, TypeScript discipline, understanding of the render cycle, CSS layout fundamentals, deployment tooling. All of it, more than I expected. A demo that stutters during a scroll is a demo that loses the room, and knowing why it stutters is a frontend skill.
Did not transfer: my instincts about what to build first. In product work you build the risky thing first to de-risk the project. In demo work you build the visible thing first, because the visible thing is the entire deliverable and the risky thing may never be seen.
Actively harmful: the completionist reflex. The urge to handle the edge case, fill in the empty state, wire up the setting that nobody will click. In product work that reflex is professionalism. Here it is scope creep against a fixed deadline, and I have burned real hours on screens that were never opened.
The uncomfortable part
There is a version of this job that is dishonest, and the line is thinner than I'd like.
A demo shows software working. It does not show software working under the conditions the prospect will actually encounter. Every demo engineer knows this. The good ones hold a line about which shortcuts are presentational and which are load-bearing.
My rule: I will fake the data, never the capability. Seed data can be invented. Response times can be optimistic. But if the demo shows a feature, the feature exists, and if the demo implies an integration works, the integration works. The moment you demo something that cannot be built is the moment you have written a check the implementation team has to cash.
That rule has cost me a few impressive-looking screens. It has also meant I have never had a post-sale conversation where someone felt misled, which I consider the actual measure of doing this job well.
Top comments (0)