We used CustomerShip to ship CustomerShip onto our own demo site
We keep a small public demo site — a plain static site with a click counter, a color mixer and a to-do list — connected to a CustomerShip app so we always have somewhere real to point people. It didn't have our own feedback widget on it yet. So rather than opening an editor and adding the script tag ourselves, we did the obvious thing: we asked CustomerShip to ship it.
The request was already sitting in the inbox
We'd raised the request the normal way — in plain language, the exact snippet we wanted added to every page — and it sat in the request inbox until we had a moment to look at it. That's the whole point of separating collecting requests from shipping them: nothing forces a decision the moment feedback comes in.
One click to see what it would take
Before we shipped it, CustomerShip had already graded it: how much of the repository it touches, how risky the change looks, and roughly how many doubloons it would cost at our chosen agent tier.
That assessment matched reality: a small, well-scoped repository, a change that only touches markup, no reason to expect surprises. We clicked Ship it.
A real pull request, about three minutes later
CustomerShip cloned the repository, made the change, and opened a pull request against the real GitHub App installation — the same one you'd use. No merge happened automatically; it landed as an ordinary PR for a human to read.
We reviewed it like we would any other PR, merged it, and GitHub Pages rebuilt the site. A minute or two later, the widget was live.
The next request to ship on that same demo site came in through this exact widget, from a real click on a real page — and it went from submission to shipped code just as quickly. That one's in the next post.