Paid for a "Custom" Site? How to Check in DevTools Whether It Is a Generator Export

Picture the situation this page is for. A founder pays an agency for a "fully custom, hand-coded" marketing site. The site arrives. It looks fine, maybe even good, and something about it feels familiar: the centered headline over a faint blue-to-violet wash, three identical feature cards, a solid blue pill button that lifts on hover. Is it custom, or is it a generator's export with a new logo?

You do not need to guess. Ninety seconds in the browser's developer tools will tell you what the page is built from, and a few more minutes will tell you whether anyone changed the defaults. This is the method, step by step.

An earlier version of this page told the story of a named founder, an agency, a $12,000 invoice and a refund, as if it had happened. It was not a documented case, so it is now what it should have been: a method you can run yourself. The scenario above is a hypothetical.

First, what you are and are not looking for

Using AI to build a client site is legitimate. Good studios do it. The question is not "was a generator involved?" but "did anyone make the decisions the invoice says were made?" A studio that generates a first pass and then re-types the site, re-colors it, breaks the stock layout apart and removes the generator's leftovers has done custom work. A studio that exports, swaps the logo and invoices for "hand-coded" has not.

The checks below find defaults. A default is not proof of a generator: a hurried human can pick Inter and Tailwind blue too. What they find, together, is whether anyone made a choice.

Step 1: the rendered font

Open DevTools (F12), go to the Elements panel, select the main heading, open Computed and find font-family.

font-family: __Inter_aaf875, __Inter_Fallback_aaf875, sans-serif;

A hashed family name such as __Inter_… or __Geist_… is what Next.js's next/font produces when it self-hosts a Google font. It tells you two things: the site is built with Next.js, and the typeface is Inter (or Geist). Next.js's own starter loads Geist and Geist Mono by default (create-next-app template), and v0 starts every chat from a Next.js app (v0 docs).

Neither font is wrong. But a brief that said "bespoke" and a typeface nobody chose do not match. The longer argument is in the Inter piece and Geist, the new Inter.

Step 2: the accent color

Select the main call-to-action button and read its computed background-color.

background-color: rgb(59, 130, 246);   /* = #3b82f6 */

#3b82f6 is blue-500 in Tailwind CSS v3. Tailwind v4 defines its palette in OKLCH, so a v4 site shows the same family as oklch(0.623 0.214 259.815) for blue-500, or oklch(0.546 0.245 262.881) for blue-600 (Tailwind's theme source). A studio with a brand designer picks a hue with intent; it rarely lands on the literal default of the most popular CSS framework. If the hero background runs from that blue into violet (from-blue-500 to-violet-500), that is the gradient discussed in the blue-purple gradient piece.

One more check while you are there: white text on #3b82f6 has a contrast ratio of about 3.68:1, below the 4.5:1 that WCAG 2.2 asks of normal text. An accent nobody chose is often an accent nobody checked.

The method for reading these values on any site is laid out in read the CSS: audit any site for AI tells.

Step 3: how the page is assembled

Surface choices can be coincidence. Construction is harder to fake. Expand the feature cards in the Elements tree and compare their class strings. A generated section often gives every card the identical string:

flex flex-col items-start gap-4 rounded-2xl border border-gray-200
bg-white p-6 shadow-sm transition-all duration-300 hover:shadow-md
hover:-translate-y-1

transition-all duration-300 with hover:-translate-y-1 is the hover-lift habit described in the hover-lift piece. Three cards with one byte-identical string and no variation at all means the cards were emitted, not designed.

Then scroll slowly. If every section fades in and rises a few pixels on the same timing, that is the default motion described in the motion slop piece.

Step 4: the stack

Open the Network tab, disable the cache and reload. Paths under /_next/static/ mean Next.js. That proves nothing on its own: a large share of new React sites use Next.js. Combined with the hashed default font and the stock palette, it narrows the picture to the stack that v0 scaffolds and many other tools favor.

Step 5: what generators leave behind

View the page source (Ctrl+U) and search the document for the builders' names and badges:

• lovable and "Edit with Lovable": Lovable shows an "Edit with Lovable" badge on published sites unless a paid plan hides it (Lovable FAQ). A badge that was hidden with custom CSS or commented out, rather than turned off in the settings, can still be sitting in the source.
• bolt.host or "Made in Bolt": Bolt's free plan shows a "Made in Bolt" badge on published sites (Bolt help center).
• "Made in Framer" and a framer domain: Framer shows its badge until a custom domain or a paid plan removes it (Framer help).
• "Made with Replit" and a replit.app address on apps published from Replit's free plan (Replit docs).

If you have access to the repository, which you should for work you paid to own, look at package.json too. A lovable-tagger development dependency is a Vite plugin published from Lovable's own repository (npm); a components/ui folder with stock shadcn/ui primitives and a lib/utils.ts holding cn() is the scaffold v0 starts from.

A badge or a build artifact is the only check here that names the tool. Everything else shows defaults.

Step 6: run a scan

The free scan checks a live page for eight common signatures (blue utility families, the blue-to-purple gradient, Inter or Geist as the page font, a three-equal-column grid, fade-up motion, frosted glass, stock button copy, soft-shadow cards) and returns a fix kit. It cannot tell you who built the site. It tells you how many defaults are still on it.

The conversation to have

If the checks come back full of defaults, lead with the work, not the verdict. Record your screen while you run the steps above, and send it with one question: "Walk me through the custom work this invoice covers." Then let the answer decide.

Three points worth making, none of them about AI:

• You paid for decisions. A custom-build price buys a typeface, a palette, a layout and copy chosen for your business. If those are framework defaults, the price and the deliverable do not match, however the site was produced.
• Defaults buy no differentiation. If your competitors' sites use the same starter, yours looks like theirs.
• Technical buyers notice. The people who can read these signals are often the ones a B2B product most needs, and they rarely tell you why they did not reply. The 30-second version of this audit is in detect an AI-generated site in 30 seconds.

What "finished" looks like

The fix is not to avoid the tools. It is to finish the job they start: a typeface with a reason behind it, an accent at a hue your competitors do not own, a hero composition that is not centered-headline-over-gradient, feature blocks with different shapes because the features are different, no generator badges, no leftover build artifacts. AI-built is not the problem. Unfinished is.

Before you sign off on a "custom" site, run the six steps. They take a few minutes, and they tell you whether you paid for decisions or for defaults. For reading the code itself, the 23 tells that reveal an LLM wrote it is the companion guide.

Revision note

Rewritten on 17 October 2026. The earlier version, "A Client Paid $12k for a 'Custom' Site. I Opened DevTools and Found Lovable. (A Forensic Story)," narrated a case with a named founder, a commented-out badge, a v0 attribute in the markup and a partial refund. It was not a documented case, and the v0 attribute could not be verified, so the story has been replaced by the method it contained, with sources for each check.