Claude Stack

Onboarding small-business operators to Claude Code by way of the stack they already run

ExperimentLive2026

Next.js · TypeScript · Vitest · Vercel

What it is

A personal experiment, and the only project here without a business behind it. It exists to get small-business operators onto Claude Code, starting from software they already own rather than from a blank terminal. Paste a website address; it identifies the tools that site already runs on, explains what each could do from inside Claude, and hands back a setup bundle to paste into Claude Code. It is aimed at people who run a company's websites but are not developers, on the premise that the barrier was never capability but not knowing this was possible. The repository carries a later working name, Skipper.

The landing page: the headline 'Take control of your company's full digital stack' above a single URL input, on a dark ground. — The whole ask on arrival: one address.

What it does

Detection reads four signal sources in rough order of reliability: HTTP response headers, markers in the HTML such as generator tags and plugin paths, DNS records, and the server's IP range. DNS turns out to be the richest and least obvious. Mail records name the email provider, nameservers name the registrar, and verification records name SaaS tools outright. It is deliberately blind to the back half of a stack — databases are server-side, and apps often sit on a subdomain that is never fetched — so having found part of the stack it asks about the rest rather than showing a blank catalog. The output is a working set of config files and a setup prompt.

The results grid after a scan of nytimes.com: a strip listing other addresses found on the domain, above nine detected tools as cards, each naming the signal it was found by and what it could do from inside Claude. — A scan of nytimes.com, run for this screenshot. Nine tools, each labelled with the signal that found it: a cf-ray header, a powered-by header, page source, MX and TXT records. The strip above them is the DNS-derived address list.

How it's built

Next.js and TypeScript with hand-written CSS. The split that matters is I/O from logic: one module does every network call, and the matching and assembly modules do none, which is what lets the interesting parts be tested against recorded captures of real sites instead of the live internet. A guard rejects private, loopback and link-local addresses before any request goes out.

Working with Claude

The decision that shaped everything was refusing to let a model do the detection. Handing the page source to Claude and asking what it saw would have been faster, and the demo would have looked identical right up until it named a tool that is not there, to a user who by definition cannot check. So detection is deterministic pattern matching, a recipe may only embed a real endpoint when that endpoint has been verified, and both rules are held in place by tests rather than by intention. Claude wrote the patterns, the fixtures and the tests that constrain its own output.