Stop describing the fix. Make it on the page.

There is a specific kind of feedback that never survives the trip: the kind about how much. “A bit more space above the heading.” “The button is too loud.” “Can the caption be one line shorter?”

None of that is hard to fix. It is hard to describe. So it turns into three rounds — a comment, a guess, a screenshot of the guess — for a change that would take four seconds if the person who noticed it could just do it.

Visual branches are for exactly that. The widget panel is called Visual branches, and its subtitle is the whole idea: edit the live page without a deploy.

What a visual branch is

A branch is a named set of changes recorded on top of the running site. Nothing is written to your repository, nothing is deployed, and production is untouched — the changes exist only for people opening that branch’s link.

Create one, pick an element, and edit it: the text itself, its colour, its spacing, its size, its typography, its background and border, or any CSS property by name. Reviewers who cannot write CSS still get real controls; developers who can drop into Advanced CSS and type the property.

Scoped, so it does not leak

The part that makes this safe is that every change carries a scope: a state, a width, a part and a theme.

• A dark-mode contrast fix is saved for dark mode and stays there.
• A mobile spacing tweak applies at that width and nowhere else.
• A hover change is previewed as if hover were active, and saved as a hover change.

There is a second axis for reach: apply to this one element, or to every element sharing its class — the difference between fixing one card and fixing all ten.

The page checks your work

Changing a colour by eye is how contrast bugs get introduced. So the panel checks as you go and answers in place: Contrast 3.1:1 — below the 4.5:1 this text size needs. The threshold follows the text size, so display type is held to 3:1 and body copy to 4.5:1.

Two layout checks run the same way: the content no longer fits this element, and this element now sticks out past the page. You find out while you are still holding the mouse, not after a client does.

Everyone is in the same room

Branches are live. If a teammate has already edited the element you are about to save, the panel says so before you overwrite anything — take theirs, or keep mine. Every change also has a Why field: one line for whoever lands it, travelling with the change instead of getting lost in a thread.

Three ways out to a developer

This is where a mock-up tool usually ends and the retyping begins. A branch has three exits instead:

1. The CSS. Copy it, or download a .css file, from the project’s Design changes section — described in the product as style edits your team made straight on the site, ready to hand to a developer.
2. A task. Turn any single change into a tracked issue, carrying its selector and its reason.
3. A prompt. One copy prompt for an AI agent, describing every change in the branch so an agent working in your repository can apply them. Pogpin never writes to your repo itself — the diff stays yours to review.

Where it changes the process

• Client sign-off. Instead of “make the hero bigger”, the client sees the bigger hero and approves the actual result.
• Design QA. A designer fixes the eight small spacing drifts themselves and hands over one CSS file, instead of eight comments.
• Content edits. Marketing rewrites the headline on the live page and shares the link, and nobody books a developer for a sentence.

Try it on your own site

Open your site through the widget, create a branch, and change one thing you have been meaning to fix. The guide walks the full flow, including scopes and the handoff: edit the live page with visual branches.

Start free — visual branches are part of the product, not a separate tool to install.