DBLSEO Scanner Case Study — One platform to run many client websites

Overview

I work at DBL SEO as a Front-End Developer and Growth Engineer. DBL SEO is a studio that helps local service businesses get found on Google — their public site is dblseo.com. This page is not the agency brochure. It is the story of DBLSEO Scanner, the product I actually build.

Scanner is an internal web app. Think of it as the studio’s back office: who is allowed to see which client, how those sites are doing in search, and how a new site gets published. The team uses Scanner; clients visit their own websites. Mixing those two up is easy if you only look at the agency homepage.

The work has two parts that feed each other. Inside Scanner I build the screens and the access rules so each company only sees its own data (identity and access management, or IAM). Alongside that, we launch client websites from shared Next.js templates — fast, search-friendly pages that Scanner then watches. Those sites stay separate. Scanner does not host 100 clients in one URL; it is the place the team goes to run them.

The Challenge

When you look after a lot of client websites, two things break first. People log into the wrong tools. And every new site is built as if it were the first one. Spreadsheets replace a real dashboard. Google Search Console is opened in twenty tabs. A new hire learns “how we do it” from whoever is free that week.

Access has to be strict. Someone from client A must never see client B’s keywords, rankings, or site health. That is what “multi-tenant” means here: one product, many companies, hard walls between them. At the same time, the people doing the work need one screen, not a scavenger hunt.

New sites also have to be findable and fast from day one, not patched after launch. If “the site is live” and “Google can actually find it” are different conversations, the studio is already behind. Scanner had to feel like one calm product for the team, and like a locked door between clients.

What I Built

On Scanner I own a large part of the interface and the front-end logic for login and permissions. Each person belongs to an organization. Every list, detail page, and change is limited to that organization. If the “which client is this?” context is missing, the screen shows nothing from another client — it fails closed. Access is not a badge in a settings page; it is the first question every screen asks.

I also work on the SEO dashboard: one place to see whether sites are in Google’s index, whether pages are slow, and where visibility moved. The goal is a to-do list, not a pretty chart. Someone should leave the dashboard knowing which sites to fix this week.

In parallel I helped turn website delivery into a repeatable path. We reuse Next.js templates tuned for Core Web Vitals (Google’s speed and stability scores) so a new site launches faster and is easier to index. Each client still gets their own site. Scanner is the control room; the websites are the storefronts. My side of the stack is Next.js, Azure, and IAM.

Results

More than 100 independent client websites shipped for one client program, built to show up in Google and measured from Scanner instead of from one-off exports. Shared templates cut the time to launch because speed, page structure, and search defaults already lived in the template — not in a last-week checklist.

The team can see the whole set of sites in one dashboard instead of jumping between tools. Organization-level login means the same product works for internal staff without mixing client data. The win is not a traffic screenshot. It is a way of working that still holds when the site count is in the hundreds.

Process is part of that result. We write down the steps, review a site before it goes live, and keep a record of what was delivered. Workflow diagrams (BPMN-style) and quality tracking (CMMI-oriented) sound heavy until the 101st site. Then they are how “done” means the same thing to engineering and to SEO.

Process

A new site starts from a template, gets reviewed, then is added to Scanner so monitoring starts on day one. That can feel like extra paperwork. Skipping it is how you spend a month later asking which client is on which setup.

On the front-end I treat that path as a contract: components that already include the search and speed defaults, screens that never show the wrong client, and dashboard states that map to real work — fix, watch, or ship. Growth engineering here is not only “make a landing page convert.” It is making the product the way the studio scales.

FAQ

How do you keep one client’s data from mixing with another’s?

Each login is tied to an organization. Every screen and every change is limited to that organization. If that context is missing, the UI shows nothing from another client. Engineers call this organization-level IAM in a multi-tenant app: one product, many companies, hard walls.

How do you launch 100+ websites without building each one from scratch?

Client sites are separate websites generated from shared Next.js templates — not one app with 100 companies inside it. The template already includes speed and search defaults. Scanner is the control room that watches the sites after they go live.

What was actually your job on Scanner?

The screens and front-end logic for who can see which client, the SEO dashboard the team uses to decide what to fix, and the template layer used to launch new sites. “Growth” here means putting those defaults into the product so the studio does not start a custom engineering project every time.

What does the SEO dashboard help the team do?

It is a work queue, not a gallery of charts. It pulls together index status, speed, and visibility so someone can leave with a list of sites to fix or watch. If a number cannot change this week’s work, it does not get the main slot.

How do you keep quality up when there are so many sites?

Shared templates, a review before launch, and written handoffs between development, SEO, and operations. Documented workflows and a quality trail make “live” mean the same thing to everyone. Without that, site 101 is always a special case.