Their JS bundle names features they haven't shipped

Every time someone opens a competitor's web app, that competitor hands them a few megabytes of their own source code. Minified, yes. Obfuscated, sometimes. But shipped, in full, to a browser they don't control.

Almost nobody in competitive intelligence looks at it. Here are the six questions people ask when they find out it's there.

What's actually inside a front-end bundle?

More than you'd guess. Modern single-page apps ship a router, and the router has to know every route the app can reach — including the ones behind a flag nobody outside the company can flip yet. Strings like /settings/billing/usage-based sit in the bundle weeks before the pricing page mentions usage-based anything.

You also get the shape of their API. Fetch calls carry endpoint paths, query parameter names, and often the field names of the response they expect. Feature-flag SDKs are worse — some initialize with the full list of flag keys in the client payload, which is effectively a list of everything the product team is currently arguing about. Add error strings, empty-state copy for screens that don't exist yet, and the occasional third-party key that tells you which analytics, support, and billing vendors they're on.

Is reading it fair game?

The bundle is served, unauthenticated, to anyone who loads the page. Reading what a public web server hands your browser is the same act as reading their pricing page — it's just less pleasant to look at.

The line is elsewhere, and it's a real line. Don't create an account under a false identity to reach code behind a login. Don't use a credential you weren't given. Don't take an endpoint you found in the bundle and start hitting it to see what comes back — that's no longer reading, that's probing someone's system, and it's the point where "competitive research" stops being a defense. Look at what's shipped to the open web, and stop there.

Which signals are actually worth the time?

Three, in descending order of payoff.

Route names. The cheapest and most legible. A new top-level route is a new product area. A route that disappears is a feature being sunset, and it usually vanishes from the bundle before the changelog or docs admit anything.

Feature-flag keys. Highest signal when you can get them, because flag names are written by engineers for engineers and carry no marketing varnish. enable_soc2_export means something different from enable_enterprise_tier.

Vendor keys and script tags. Switching from one analytics vendor to another is a small thing. Switching billing providers is not — that's a months-long project that usually precedes a pricing model change.

Ignore the rest. Component names, CSS class hashes, and internal variable naming feel like insight and aren't.

How do I tell an unreleased feature from dead code?

Mostly you can't, from one look. That's the honest answer, and it's why this tactic pays off on repeat checks rather than one-time digs.

Dead code sits still. A route that's been in the bundle unchanged for eight months is scar tissue from something they killed. A route that appeared last Tuesday, alongside three new flag keys with the same prefix, is a team actively building. The signal isn't the string — it's the string's arrival date. Same principle as everything else on this blog: you can't diff against memory, so if you didn't record last month's bundle, this month's tells you very little.

How often should I check?

Rarely. This is a deliberate, hour-long exercise you run when something else has already made you curious — a hiring spike, a new sitemap entry, a repositioned homepage. It is not a weekly ritual, and treating it as one is how competitive programs die of overhead.

The surfaces around the bundle are the ones worth watching continuously, and that's the split we built Seeto around: it monitors public pages — pricing, docs, changelogs, integrations, positioning — and surfaces the differences as discrete change events, so you find out that something moved without checking anything by hand. It doesn't decompile bundles, and it won't tell you what a flag key means. It tells you when to go looking, which is the part that actually gets skipped.

What do I do with what I find?

Less than you want to. A flag key is a hypothesis, not a roadmap. The failure mode here is dramatic: someone finds enable_ai_agent in a competitor's bundle, and two weeks later there's a slide deck claiming the competitor is pivoting to agents.

Write it down with a date and a confidence level, and wait for a second source. When the careers page opens a role that matches, or the docs sprout a stub page, or the pricing tiers reshuffle — now you have something. One signal from one surface is noise most of the time. The bundle's job is to give you the earliest of the three dots, not to draw the line.

Their engineers ship you the evidence every deploy. The discipline is in not over-reading it.