Case · JKC Media, Eindhoven
The agency that built WebCrew runs every client site on it. This is what that looks like.
JKC Media is a digital agency in Eindhoven: strategy, design, development and marketing for businesses since 2017, most of them on WordPress. Its client sites were the first ones WebCrew watched, and they still are. Here is how a week runs there now.
No client names or figures are used without permission. Sites in the log below are described, not named.
Before
A monitoring tool here, an update plugin there, and a phone that rang first
Like most agencies, JKC looked after client sites with a mix: an uptime service, a maintenance plugin per site, a spreadsheet of logins, and a developer who did the update round on Fridays. It worked until it did not.
- Downtime came in by phone. The client noticed, then the account manager, then a developer. The order was wrong.
- Updates were a Friday afternoon. Site by site, login by login, and a restore only if somebody had made a backup that week.
- Security was a plugin per site. Good inside one site, blind across forty. Nobody could answer "which of our sites run that version?" in under an hour.
"We were the agency that had to explain a change nobody signed off on, and the agency that heard about downtime from the client. Both once too often. The scripts we wrote to stop that became WebCrew."
Justin van DongenFounder, JKC Media · Co-founder, WebCrewNow
A week at JKC Media with WebCrew running
Times are typical; sites are described, not named.
- Mon 08:30The first look takes four minutes.
One dashboard, every client site. Six updates waiting, zero findings open, everything up. The developer on duty approves the six from the dashboard; each one takes a restore point first and keeps the code difference.
- Tue 14:02A webshop returns 502 from both regions.
The alert reaches the developer with the response code and the last change on the site. The host had restarted PHP. Seven minutes later the shop answers again; the log has the incident, the client hears it from JKC, not the other way round.
- Wed 10:15A page-builder advisory is published.
The dashboard lists which client sites run the affected version. The fixed version is approved on all of them within the hour, with a restore point on each. The question that used to take an afternoon is answered by a filter.
- Thu 11:20Opening hours change on a client site, in three places.
The client asks in wp-admin, the assistant drafts the change in the contact page, the footer widget and the schema block, and the client approves it. Nobody at JKC touched it; the log says who asked and who approved. This is the part that is rolling out account by account.
- Fri 16:00The Friday update round no longer exists.
The developer who used to do it looks at the versions per site instead: two sites on a PHP version that reaches end of life in two months, flagged, planned for next sprint. Then the weekend.
What changed
Three things the team would not give back
Knowing first
Downtime, a new administrator, a changed core file: the alert arrives before the client's e-mail does. The conversation with the client starts with "we saw it and fixed it" instead of "let us look into it".
A way back, every time
Every update and every draft has a restore point and a stored difference. Approving an update on a Friday stopped being brave.
One answer for forty sites
"Which sites run that version?", "which sites are on PHP 8.1?", "what changed on that site this week?" are one question in the dashboard, or in Claude, instead of a round of logins.
How it is set up
SSH where the host allows it, the connector plugin everywhere else
Sites on JKC's own servers connect over SSH with a key scoped to the site's user, so the file-level checks and the full restore points run. Sites on managed hosts without shell access use the connector plugin. Both show up in the same dashboard.
- One agency account, every client site. Billed per site, the team never counted.
- Roles per site. Developers approve updates; account managers read; some clients approve their own drafts.
- Claude and Cursor connected over MCP. Developers ask about the sites from the tools they already have open.
"The honest part: our own sites are where the rough edges get found first. When something in WebCrew is wrong, a JKC developer hits it before a customer does. That is the arrangement, and we would not want it the other way round."
Rik SmeetsDeveloper, JKC Media · Co-founder, WebCrewRun your client sites the way the agency behind WebCrew runs its own
Free for one site, no card. Connect the first one in five minutes.