How to Spot a Competitor Launch Before the Announcement

Product launches leak for weeks before the announcement. A staging subdomain appears in a public certificate log the moment its HTTPS certificate is issued. A job posting describes a role that only makes sense for a product that does not exist yet. A pricing page gains a row. Ad copy starts testing unfamiliar language. Individually each is weak. Stacked, they point somewhere.

This post covers what those signals are, how the most reliable one actually works at a technical level, and what it cannot tell you.

Certificate transparency is the earliest signal

When a company puts anything on the public internet over HTTPS, it needs a certificate. Getting one leaves a public record, by design.

Certificate Transparency is a system of append-only logs that record issued certificates. It exists for security reasons: if a certificate authority issued a fraudulent certificate for a domain, the domain's owner needs a way to discover it. Making every issuance publicly visible turns that from an impossible problem into an observable one.

The side effect is that infrastructure becomes visible before the product it supports.

How the logs actually work

Worth understanding properly, because the mechanism is what makes the data trustworthy.

The logs are append-only ledgers, and they are cryptographically verifiable. Each log builds a Merkle tree: certificates are hashed as leaves, those hashes are combined pairwise up the tree, and the log signs the resulting root hash to produce a Signed Tree Head. Because every leaf feeds into the root, any modification to a logged certificate changes the root hash. You cannot quietly remove an entry after the fact and still produce a valid, consistent tree.

Submission produces a receipt. When a CA submits a certificate, the log immediately returns a Signed Certificate Timestamp, which is the log's cryptographic promise to include that certificate within a window known as the Maximum Merge Delay, typically 24 hours. The SCT is attached to the certificate itself as an X.509v3 extension.

Precertificates resolve a deadlock. A certificate should carry SCTs, but a log cannot issue an SCT for a certificate that does not exist yet. The solution is the precertificate: it contains all the same information as the real certificate plus a poison extension that makes user agents refuse it. The CA submits the precertificate, collects SCTs, then issues the real certificate with those SCTs embedded.

Browsers enforce it. Both Chrome and Safari require at least two SCTs, depending on certificate lifetime. That enforcement is what makes the logs comprehensive in practice: a certificate that was never logged is a certificate that will not work in mainstream browsers, so effectively everything public gets logged.

Monitors watch the logs. Publicly run servers periodically poll every log and check for certificates of interest, verifying inclusion and consistency using cryptographic proofs rather than trusting the log's word.

The practical upshot for you: the moment somebody at a company requests a certificate for app-v2.theircompany.com or newproduct.theircompany.com, that name becomes public. Often weeks before anyone writes a press release. You can look this up yourself with our free subdomain finder, or read more about certificate transparency monitoring.

What certificate transparency does not show you

This is where most write-ups oversell it, so be clear about the limits.

Wildcard certificates hide the names. A certificate issued for *.theircompany.com covers every subdomain without naming any of them. Organizations that use wildcards broadly are substantially less legible in the logs, and some do this deliberately.

Internal names may never appear. Infrastructure that is not reachable from the public internet, or that uses an internal CA rather than a publicly trusted one, does not need a publicly logged certificate.

A certificate is not a launch. Names get registered for experiments that are killed, for internal tools, for vendor integrations, and for things that get renamed before release. Reading a single subdomain as a confirmed product is how people embarrass themselves publicly.

That last point is the reason the technique works as pattern recognition and fails as prophecy.

The other signals

Job postings. Roles describe work that does not exist yet. A specialist hire in an area a company has never operated in, or a cluster of postings on one team, describes a plan with a budget attached. Job descriptions also routinely name technologies and responsibilities that are more specific than anything in the company's marketing.

Pricing and positioning pages. Companies rewrite these far more often than they announce anything. A new row in a pricing table, a tier renamed, a claim quietly removed, or a compliance badge added are all decisions somebody made. Removals are the more interesting half and almost nobody watches for them.

Ad copy. Advertisers test language before they commit to it. When the claims in a competitor's ads start shifting, the positioning changed first, and ad transparency data makes that observable.

Documentation and changelogs. Developer-facing surfaces often move before marketing does, because they ship when the code ships rather than when the campaign is ready.

Stacking weak signals

No single item above is worth acting on. The method is correlation.

Three subdomains appear over a fortnight that share a naming theme. Two job postings go up for roles that only make sense alongside that theme. The pricing page gains a placeholder row. Now you have something, not because any one signal is strong, but because the probability of three unrelated things pointing the same direction in the same window is low.

The discipline that matters is writing down what you observed and when. A dated note turns "I had a feeling" into a claim you can check yourself against later, and it is also the raw material for a post.

Turning a signal into a post

Here is where this becomes a personal branding advantage rather than only a competitive one.

The window between the signals appearing and the official announcement is the only period where your analysis is genuinely early. Publish during it and you are the person who saw it coming. Publish after the launch post and you are one of several dozen people reacting to the same announcement.

Two rules make this safe to do in public.

Describe evidence, not conclusions. "Three subdomains matching this pattern appeared in certificate transparency logs this month, which usually indicates a staging environment" is defensible. "Company X is launching Y next month" is a prediction you cannot support and may have to retract.

Be explicit that you are reading signals. Showing your reasoning is more interesting than asserting a conclusion anyway, and it means being wrong costs you nothing, because you told the reader what you were working from.

Done that way, this is one of the most reliable ways to turn the signal into a post that nobody else in your market could have written that week, which is what a personal branding strategy built on real signals looks like in practice. If you want to run this analysis through an assistant rather than by hand, competitive intelligence in Claude covers that workflow.

Frequently Asked Questions

How can you tell a competitor is about to launch something?

Watch for correlated weak signals: new subdomains appearing in certificate transparency logs, job postings describing roles for unreleased work, new rows or removed claims on pricing pages, and shifts in ad copy. No single signal is reliable, but several pointing the same direction within a short window usually is.

What are certificate transparency logs?

Public append-only ledgers that record every certificate issued by participating certificate authorities. They exist so fraudulent certificates can be detected, and they use Merkle trees so entries cannot be altered or removed undetectably. Chrome and Safari require certificates to carry proof of log submission, so coverage of public sites is effectively complete.

Is monitoring certificate transparency logs legal?

Yes. The logs are public by design and intended to be queried by anyone. Their entire purpose is external auditability, and publicly run monitors polling them is the system working as specified rather than a loophole in it.

Can companies hide their subdomains from certificate transparency?

Partly. A wildcard certificate covers every subdomain without naming any, so organizations using wildcards broadly reveal much less. Infrastructure that is not publicly reachable, or that uses an internal certificate authority, may never appear at all. The logs show public certificate issuance, not everything a company is building.

How early do these signals usually appear?

It varies and there is no dependable rule. Certificates get issued when someone stands up an environment, which can be weeks or months before a launch, or days. Treat the timing as unknown, watch for signals accumulating rather than for any single one, and avoid stating a launch date you cannot support.