Case Study Agency partner

An agency's clients never see us. That is the job.

Merrick Creative builds brands, and its clients expect their websites to simply work. We run hosting, security, and launches behind the scenes, under the agency's name, so its clients only ever deal with the agency.

  • Since 2024 their hosting partner
  • 30+ sites hosted, live and staging
  • 6 data center regions
  • On request staging and review sites

An agency whose clients expect the website to just work

Merrick Creative describes its work as "Branding, marketing, PR, and podcasting for brands and places that refuse to blend in." Websites are part of what it delivers, and once a site is live, the client expects it to stay that way.

The person who feels that expectation is the account lead. They own the client relationship and they promise the launch date. If a client's site goes down, or its inquiry form goes quiet, they take the call. Every outage, expired certificate, and slipped launch lands on the agency's name, and none of it is the work the agency was hired to do.

Servers were never supposed to be the agency's job

Before we came in, the agency looked after hosting on servers they ran themselves. With a few sites, that is manageable. With more than thirty, counting the ones still in development, it becomes a second job: updates, certificates, backups, and a server that wants attention on a Saturday.

Each hour spent there was an hour a creative team was not spending on creative work. And when something went sideways, the account lead was the one explaining a hosting problem to a client who had hired an agency for its ideas.

The agency wanted someone to take that whole layer off its hands. It did not want a second vendor its clients would have to know about.

How we run it without anyone seeing us

We stay invisible. No FatLab name, logo, or support link appears on any site we host for them, so the agency's clients only ever deal with the agency.

We work inside their process. Requests reach us through the agency's own project system, and our project manager answers there, so the account lead never has to learn a new tool or forward an email.

New sites launch onto hosting that is already live. When a redesigned site replaces an old one, we move the new build into the place the old one occupied, so the domain, the certificate, and the firewall stay where they are. The account lead does not have to ask a client for a registrar login on launch morning, and nobody waits on a DNS change.

We check the inquiry forms around every launch. A rebuilt site can look finished while its form notifications quietly go nowhere. For a site whose whole job is collecting inquiries, that means lost prospects nobody notices for weeks. So we send real test submissions before the cutover and again after it, and we confirm they arrive.

When the agency's developers need somewhere to build, or a client needs somewhere to review, we stand up a staging site on request.

What the agency no longer thinks about

Today the account lead promises a launch date without thinking about servers. Developers ask for a staging site and get one, along with access to the sites they are working on. The agency's clients see the agency, a site that loads, and inquiries that arrive.

The client relationships stayed where they belong, with the agency. The server work moved to us. We remain in the background, which is where this arrangement needs us to be.

What changed

  • The agency's clients deal only with the agency on every site
  • A new site can launch onto hosting that is already live, with no DNS change
  • Inquiry forms are tested for real delivery before and after every launch
  • Developers get a staging site and their own access when they ask

Under the hood

For the developer evaluating us
  • Dailyoffsite backups
  • Enterpriseweb application firewall
  • AutomaticSSL certificates
  • Per siteisolated resources
  • Per siteSFTP and SSH for developers

What We Built

  • White-label managed hosting with no FatLab branding on any site
  • Launches onto live hosting with no DNS change
  • Form delivery testing around every cutover
  • Staging and review sites on request
  • Per-site developer access

Hosting layout

Each site runs as its own application with isolated resources, spread across six data center regions so a site sits near its audience.

Security and backups

Every site sits behind Cloudflare Enterprise (WAF and CDN) with Imunify360 on the server, automatic SSL certificates, and daily offsite backups. Breeze handles page caching, with Object Cache Pro on Redis where a site benefits from it.

Launch method

A new build is migrated onto the existing production application, or the existing Cloudflare service is transferred to the new application. Either way the hostname, certificate, and firewall rules carry over with no DNS edit. A database import replaces a site's mail settings, so those are re-applied after migration and a test submission is traced through the mail service before and after cutover.

Developer access

SFTP and SSH credentials are issued per site, so a developer reaches only the sites they are working on.

Figures current as of September 26, 2026

More stories like this

Need a development team behind your agency?

Tell us what your clients need, and we will tell you how we would support it.