How We Detect the Backend Behind Any Website
A look under the hood at how oneprompt fingerprints the tech stack behind any site — and why the backend matters more than the UI when judging cloneability.
Why the frontend tells you almost nothing
Anyone can screenshot a website, feed it to an AI coding tool, and get back pixel-close HTML and CSS in ten minutes. That's not news anymore, and it's exactly why the frontend is the wrong place to look if you actually want to know whether a business is cloneable. A login form, a pricing table, a dashboard with charts — these are commodity UI patterns that every design system on earth already knows how to reproduce.
The real question is what's running behind that UI: what database it hits, what third-party APIs it depends on, what state it manages, and what happens when 10,000 people use it at once instead of one demo user. That's the layer we actually try to detect, because that's the layer that determines whether 'clone this' means a weekend project or a six-month engineering effort with a compliance team attached.
The passive signals: headers, cookies, and error pages
Before we touch anything invasive, we look at what a server volunteers for free. Response headers are the most underrated fingerprint on the internet — a Server header, an X-Powered-By, a Vary on a specific cache key, or even the exact casing of a header name can point to Express, Rails, Django, or a specific CDN edge config. Cookies are just as loud: a connect.sid screams Express with express-session, a laravel_session or XSRF-TOKEN pair screams Laravel, and a JSESSIONID is basically a Java backend waving a flag.
Then there's the stuff developers forget is public: 404 and 500 error pages, robots.txt, sitemap.xml structure, favicon hashes, and the exact formatting of JSON error responses. A default Rails error trace leaking in production tells us more about engineering maturity than the entire marketing site does. None of this requires sending a single malicious request — it's all sitting there in a normal browser request/response cycle.
Reading the network tab like a detective
The frontend has to talk to something, and that conversation is visible. We trace every XHR and fetch call a page makes, then classify the API shape: REST with predictable resource paths, GraphQL with a single /graphql endpoint and operation names, or RPC-style calls that hint at gRPC-Web or tRPC. The naming conventions alone are informative — snake_case JSON keys often mean a Python or Ruby backend, camelCase often means Node, and deeply nested envelope objects with a 'meta' field are a classic sign of a hand-rolled API versus a generated one.
We also watch for the fingerprints of specific platforms riding along for the ride: a Stripe.js load and a specific webhook path pattern, a Firebase SDK initializing with a project ID we can look up, a Supabase anon key sitting in a bundled JS file (yes, this happens constantly and yes, it's usually fine because RLS is supposed to handle it — usually), or an Algolia search key that tells us search isn't custom-built at all.
JS bundles are a confession, not a black box
Minified JavaScript feels obfuscated but it isn't, not really. Bundlers leave fingerprints — Webpack's chunk naming conventions, Vite's module hash format, Next.js's __NEXT_DATA__ blob sitting right in the page source with the entire server-rendered props payload attached. That single object alone often tells us the framework, the routing structure, and sometimes the exact API response shape the page was built from, all without executing a line of code adversarially.
Source maps, when they're accidentally shipped to production (more common than any CTO wants to admit), are basically the whole game over — readable component names, folder structure, sometimes internal comments. Even without maps, we can identify state management libraries by their global window objects (__REDUX_DEVTOOLS_EXTENSION__, a Zustand store shape, an Apollo cache key format) and infer the data layer from that.
Infrastructure fingerprinting: DNS, CDN, and hosting
We layer in DNS and network-level signals too. CNAME chains reveal hosting: a target pointing at Vercel, Netlify, Fly.io, Render, or an AWS CloudFront distribution ID tells us a lot about scale assumptions and deployment model. TLS certificate details, ASN lookups, and reverse IP ranges narrow it further — a site sitting behind Cloudflare with specific cache-control headers is a very different architecture story than one hitting a bare EC2 instance directly.
We also check for platform-specific tells that only exist because of how certain PaaS providers inject things: Vercel's x-vercel-id header, Netlify's x-nf-request-id, Heroku's dyno metadata leaking into error pages under load. None of these are secrets. They're operational exhaust that any request logger would capture, and stitched together they build a surprisingly complete picture of the deployment topology.
What we can't see — and why that's the actual moat
Here's the honest part: detection tells you the shape of the stack, not the substance behind it. We can tell you a site runs on Postgres with a Node API behind a Node/Express server on Fly.io. We cannot tell you about the years of data in that Postgres instance, the fraud-detection heuristics tuned on millions of transactions, the support team's institutional knowledge, or the exclusive data-sharing agreement with a payment processor that a new entrant can't just sign on day one.
This is exactly the split oneprompt is built to score. Technical cloneability is about the stack we can fingerprint — if it's a CRUD app on a popular framework with a couple of well-known third-party integrations, an AI coding tool can scaffold something structurally similar fast. Business moat is everything detection can't touch: proprietary data, network effects between users, regulatory licenses, brand trust, integration lock-in with enterprise customers. A site can be 95% cloneable at the code level and still be a terrible clone target because the moat lives in places no header or bundle will ever reveal.
How this actually changes your build-vs-clone decision
If our scan shows a generic REST API, a well-known auth provider like Auth0 or Clerk, Stripe for billing, and Postgres via a standard ORM, that's a low-moat, high-cloneability signal — the value is almost entirely in product decisions and distribution, not engineering. That's a green light for 'prompt it yourself' if you have the market access. If instead we see custom-built recommendation infrastructure, a proprietary matching algorithm hit via internal RPC calls, or evidence of large-scale data pipelines that clearly took years to tune, the code is the easy 20% and the real moat is invisible to any scanner — that's when cloning the UI gets you nothing but a demo.
The point of stack detection isn't to hand you a blueprint for theft. It's to give you an honest read on where the actual value sits before you burn three months rebuilding a login flow that was never the hard part to begin with.
Want the same teardown for any site?
Analyze a site →