Your Running App Is Already a Design Tool

Designers spend enormous effort on documents that approximate a thing. Mockups, flows, specs, prototypes, annotated screenshots — all of them a lossy translation of the thing that will eventually ship. When the real thing finally exists, the documents become stale the moment the developer commits their first deviation.

Meanwhile, the real thing is already running. In a browser tab. On a localhost port. Right there.

That running app is the highest-fidelity design artifact anyone on the project will ever have. Real typography with real font loading. Real layout at the real viewport. Real interaction. Real edge cases. Real states. It is not an approximation. It is the thing.

And yet we treat it as an output. Something that gets looked at, screenshotted, compared against the mockup, and then modified by opening up a code editor in another window and reasoning about it symbolically.

The canvas is already there

Every production web application is a living, interactive canvas. When you resize the window, elements reflow according to the exact breakpoint logic that will ship to users. When you hover a button, the transition plays at the same speed it will play on production. When you open a long list, the overflow behavior is the real overflow behavior.

Nothing else in the toolchain has this property. Figma can approximate reflow with auto-layout, but only for the layouts you manually set up. Sketch can show states, but only the states you drew. Even the most elaborate Figma prototype is a stage-managed illusion that breaks the first time someone types an unexpected character into a text field.

The running app doesn't have states. It has behavior. That's a different category.

The irony of how we work

Here's the strange part. When a designer opens Figma to "design a feature," what they are usually doing is: looking at screenshots of the existing app, deciding what a modified version of it should look like, and then producing a new document that represents that modification.

The source material is the running app. The output is a document. The document is then handed to a developer whose job is to translate the document back into a modification of the running app.

The whole process is a round trip through an inferior representation. The only reason it exists is that the designer didn't have a way to modify the running app directly.

If you could modify the running app directly — click an element, change its spacing, move it, restyle it, and have those changes flow back to the code — the intermediate document would mostly be unnecessary. You would design in the thing instead of designing about the thing.

This isn't a new idea. It's how physical product design works. Industrial designers sketch, yes, but they also spend enormous amounts of time handling the actual prototype. The mockup and the prototype are complementary, not substitutes. Software design has been unusually dependent on upstream mockups because the prototype has historically been expensive to produce and modify.

That has quietly changed.

What has changed

A modern web stack is malleable in a way it wasn't ten years ago. Hot module replacement means code changes appear in the browser within tens of milliseconds. Design tokens in the codebase mean visual decisions are expressed as data, not as hand-written CSS. Component libraries mean most UI is assembled rather than composed from scratch. AI code generation means the first draft of an app can exist before a designer has opened their tool of choice.

Taken together: the running app now shows up earlier, changes faster, and expresses its visual decisions more structurally than any mockup can. The gap between "the designed thing" and "the running thing" has collapsed.

The only remaining obstacle is the interface. You can't click on a running app and change it. You can inspect it in DevTools, but any change you make evaporates. You can read its source code in an editor, but the editor shows you text, not visuals.

Bridging that obstacle — making the running app directly editable — is the real unlock.

The mental shift

If you take seriously the idea that the running app is the design tool, a lot of downstream assumptions get revised.

Mockups become sketches. Useful for early exploration, meetings, and aligning on intent. Not useful as detailed specs. Don't put 40 hours into pixel-perfecting a mockup the code is going to diverge from in week two.

Visual decisions belong in the codebase. Design tokens. Tailwind config. CSS custom properties. If a color lives only in Figma, it's not really the system color — it's a wish. The system color is whatever the code actually renders.

The designer's tool is the codebase. Not necessarily writing code, but operating on it. Editing classNames, adjusting token values, composing components. The modern designer's leverage is over these artifacts, because these artifacts are what users experience.

Design reviews happen in the browser. Not in a mockup review meeting. You open the feature branch, you click around, you point at things, you change them together. The artifact and the conversation are the same object.

What developers get wrong about this

Developers sometimes hear "the running app is the design tool" and conclude that visual refinement is somehow second class — that the real work is in the code and the visual layer is just a skin.

That's exactly backwards. The visual layer is the product. Users interact with the visual layer. They judge the company by the visual layer. The code is only meaningful insofar as it produces the visual layer users can use.

Treating the running app as the design tool doesn't diminish code. It elevates visual work from "something a designer does in a separate application" to "something anyone with taste and access to the code can do directly." That's a more serious kind of design practice, not a lesser one.

Where this leads

If you accept the premise — that the canvas is already there, and the only missing piece is a way to edit it directly — a lot of longstanding workflow pain becomes fixable. The handoff dies, because there's no handoff. The mockup drift dies, because there's no mockup to drift from. The spec document dies, because the spec is the code.

What's left is a tighter loop: see the thing, change the thing, see the thing again. The whole discipline of software design gets to become what industrial design has always been — iterative work on the real object, not speculative work on a representation of it.

The running app is already a design tool. You just need a way to reach into it.