# StackScope

> Tech stack intelligence for new product launches.

StackScope is an independent directory of new product launches, annotated with the tech behind them. We crawl publicly-posted launches from Product Hunt, Hacker News, and PeerPush, analyse each site, and publish what it's built with.

This is the single-file LLM-ingest copy. A shorter navigation version lives at [stackscope.dev/llms.txt](https://stackscope.dev/llms.txt).

## About

StackScope.dev pulls new launches from Product Hunt, Hacker News, and a few other sources, then crawls each site to extract what it's built with: frameworks, hosting providers, CDNs, DNS configuration, security posture, and the SaaS tools loaded on the page. Every signal comes from content that a regular browser would load. We don't log in, submit forms, or touch anything behind a login.

Why we built it: knowing what tech a founder shipped their launch on is surprisingly hard. The big web-scale directories don't specialise in new launches and tend to miss the patterns that indie and early-stage products ship with. StackScope is narrower: brand-new sites, solo-founder builds, AI-first products, early-stage SaaS.

StackScope is an independent project. It is not affiliated with any other product, service, browser extension, repository, or company that uses the StackScope name.

Contact: hello@stackscope.dev

## Crawler (StackScopeBot)

User-Agent: `Mozilla/5.0 (compatible; StackScopeBot/1.0; +https://stackscope.dev/bot)`

What the crawler does for each launch:

- Fetches the main page of the launch (one HTML request)
- Renders the page in a headless browser to capture a screenshot and the final DOM (this executes JavaScript)
- Fetches up to 5 linked stylesheets to analyse CSS
- Checks a few well-known files: `robots.txt`, `llms.txt`, `security.txt`, `sitemap.xml`, `ads.txt`, `humans.txt`
- Looks up DNS records for the domain
- Performs a TLS handshake to read the SSL certificate
- Looks up the domain's ASN and registration date from public registries
- Fetches privacy policy and terms of service pages if linked from the homepage

What the crawler does not do:

- Does not spider your site. Only the homepage and explicitly linked legal / well-known pages are fetched.
- Does not submit forms, click buttons, or interact with the page.
- Does not attempt logins or access authenticated areas.
- Does not re-crawl on a fixed schedule. Occasional re-crawls happen on user request, or to apply a bug fix or schema change across the corpus. These may be partial (e.g. refreshing only headers) rather than a full re-fetch.

Crawling etiquette:

- Default rate: at most 1 request every 3 seconds globally. Never parallel requests to the same domain.
- Respects `robots.txt` rules for both `StackScopeBot` and wildcard (`*`) user-agents.
- Honours `Crawl-delay` directives. If your robots.txt specifies a longer delay, we use it.
- Does not attempt sensitive paths (admin, login, API endpoints).

How to block or slow down the crawler:

Block entirely:
```
User-agent: StackScopeBot
Disallow: /
```

Slow down:
```
User-agent: StackScopeBot
Crawl-delay: 10
```

Removal requests: email hello@stackscope.dev with the launch URL. All removal requests are honoured without needing a reason. We delete all existing data, hide the launch page (public URL returns a real 404), and add the domain to our do-not-re-import list so it will not come back on future source pulls.

## Methodology

Every score on StackScope is computed from publicly observable signals. We analyse HTTP headers, rendered page content, DNS records, TLS certificates, and well-known files. Nothing is subjective. Scores are deterministic and reproducible. The full write-up lives at [stackscope.dev/methodology](https://stackscope.dev/methodology).

### StackScope Score (0-10)

Our headline score. A single number that captures a site's production-readiness posture, based on four weighted components:

- Security (~28.6%): security headers present out of 6.
- Launch Readiness (~28.6%): page basics, social tags, responsive design, production hygiene.
- Legal (~21.4%): privacy policy, terms of service, no unfilled template placeholders.
- Web Standards (~21.4%): robots.txt, sitemap, responsive viewport, HSTS.

The score is displayed as 0-10 with one decimal place. A score of 9+ means the site is well-built across all dimensions. Files like `/.well-known/security.txt` and `llms.txt` are detected and shown on the launch page as optional best practices, but they do not affect the StackScope Score. A perfect 10 is reachable without them.

The Vibe Score / AI-Built signal is displayed on every launch page but is NOT part of the composite. It was removed from the score on 2026-04-23. We continue to surface the number as informational context only.

### Vibe Score (0-100)

Measures how strongly a site's code matches patterns we've empirically observed in AI-assisted builds. A higher score means more of those patterns are present. This is a pattern match, not a verdict. We compare each site against signals we saw consistently across hundreds of controlled AI-generated sites and report how many of those signals are present. Whether the site was actually built with an LLM is a separate question we cannot answer from the outside.

The Vibe Score is not a judgement. Using LLMs as a build tool is a legitimate choice and plenty of well-crafted sites use AI assistance. The score simply reflects how many of the fingerprints we catalogued are present on a given page. No single signal is conclusive. The score only gets high when multiple independent signals align. A score of 0 means we detected none of the patterns, which does not necessarily mean the site wasn't AI-assisted, only that we did not find our fingerprints.

### Launch Readiness (0-100)

Measures whether a site is properly prepared for launch day. The basics that visitors, search engines, and social platforms expect. We check for:

- Custom page title and meta description
- Social sharing tags (Open Graph, Twitter cards)
- Canonical URL
- Mobile responsiveness
- Production hygiene (no debug artifacts exposed)
- Legal pages (privacy policy)
- Basic branding (favicon)
- Semantic HTML (proper use of nav, main, article elements)

Score is normalised to 0-100. A perfect score means all checks pass. Sites with unfilled placeholder content (e.g. default API keys, scaffold titles) receive a penalty.

### Security Headers (0-6)

Counts how many recommended security headers are present in the HTTP response. We check for six modern headers:

- Strict-Transport-Security
- Content-Security-Policy
- X-Frame-Options (CSP `frame-ancestors` directive is accepted as a substitute)
- X-Content-Type-Options
- Referrer-Policy (an equivalent HTML `<meta name="referrer">` tag is accepted as a substitute)
- Permissions-Policy (the deprecated `Feature-Policy` header is accepted as a substitute)

The legacy `X-XSS-Protection` header is tracked but not scored. MDN documents that it is deprecated in favour of Content-Security-Policy, and it can introduce XSS vulnerabilities in otherwise safe sites.

Some large platforms (e.g. Google, Cloudflare) handle security at infrastructure level rather than through HTTP headers. A low header score on these sites does not necessarily indicate poor security, just that the protections are applied at a layer we cannot observe.

### Infrastructure

For each site we collect infrastructure data from public sources: the hosting provider and country behind the site's IP address, TLS certificate details (issuer, expiry), and domain registration data via RDAP (the modern WHOIS replacement).

Some TLDs (.io, .co, .me) do not support RDAP and will not have domain age data. Sites hosted on platform subdomains (e.g. .vercel.app, .netlify.app) show the platform's domain data, not the project's.

### AI Stance

Classifies a site's position on AI crawlers based on their public declarations:

- Open: actively provides content for AI systems (e.g. has an llms.txt file)
- Blocking: explicitly blocks known AI crawlers in robots.txt
- Confused: blocks AI crawlers in robots.txt and publishes an llms.txt welcoming them
- No stance: no public declaration either way

### Technology Detection

StackScope uses its own fingerprint detection engine: a curated catalogue of technology fingerprints with hand-authored detection rules, built from real crawl observations and continuously growing. JavaScript is executed in a real browser engine, so detection sees the rendered page, not just the static HTML.

The fingerprint catalogue is not based on Wappalyzer or any third-party pattern database. Every rule is derived from observations in our own crawl data, verified by human review, and tested against the live corpus. New fingerprints are added daily as the crawler discovers new technologies in the wild.

### Screenshots

We capture a viewport screenshot of every site using a headless browser. This gives an accurate representation of how the page actually renders, including JavaScript-rendered content.

### Data Sources

We discover new product launches from multiple sources:

- Product Hunt: daily launches via their API
- Hacker News: Show HN posts via the Firebase API
- PeerPush: recent launches via their public API

Sites on major platforms (e.g. Amazon, Netflix, Apple) and marketplace listings (e.g. Shopify app store, Chrome Web Store) are filtered out. We focus on independent products with their own websites.

### Deterministic, no LLM in the pipeline

All scoring and classification is performed by deterministic, auditable code. StackScope does not call any large language model or external AI service at any point in the detection or classification pipeline. Every fingerprint rule and every scoring threshold is hand-written and can be traced to a specific line of code.

## Privacy

### What StackScope does

StackScope is a public directory that analyses the technology stacks of product launch websites. We crawl publicly accessible web pages and extract technical information: frameworks, hosting providers, security headers, DNS records, and other signals that are already visible to anyone with a web browser.

### What we collect about websites

For each website we analyse, we store:

- The website URL, name, and description
- HTTP response headers
- Publicly accessible HTML content (rendered in a headless browser)
- Up to 5 linked CSS stylesheets from the page
- Well-known files if present: robots.txt, llms.txt, security.txt, sitemap.xml, ads.txt, humans.txt
- Privacy policy and terms of service pages, if linked from the homepage
- DNS records, TLS certificate details, hosting provider, and domain registration data
- A viewport screenshot of the page
- Detected technologies, scores, and analysis results

All of this information is already publicly available. We do not access any authenticated areas, submit forms, or interact with websites beyond loading the page.

### What we collect about visitors

Almost nothing. StackScope sets no cookies, runs no third-party analytics, tracking scripts, or advertising, and has no user accounts. Standard web server logs are deleted after 30 days. See the [privacy policy](https://stackscope.dev/privacy) for the authoritative version.

### Website removal

If you are a website owner and would like your site removed from StackScope:

- Email us at hello@stackscope.dev. We will delete all existing data, hide the launch page, and add your domain to our do-not-re-import list. No reason required.
- Disallow `StackScopeBot` in your robots.txt. This prevents future crawls but does not retroactively remove data already published. For full removal, email us.

### Data storage

All data is stored on our own infrastructure in a local database. We do not use third-party analytics, advertising, or data processing services for visitor data.

### Contact

- General: hello@stackscope.dev
- Privacy: hello@stackscope.dev