Research guide

How company pages in companies/ are researched and written.

Last updated: 2026-07-29.

Repository layout

Each company has its own directory, named with a stable lowercase slug:

companies/
  README.md
  README.zh-CN.md
  company-name/
    README.md
    README.zh-CN.md

The two files directly under companies/ are the English and Simplified Chinese company indexes. Within each company directory, README.md is the canonical English research page and is displayed by default when browsing the directory on GitHub. README.zh-CN.md is its Simplified Chinese translation. Additional company-specific assets or data may be kept in the same directory.

Translated pages must preserve the English page's section structure, figures, dates, distinctions between fact and inference, and source links. Research findings should be added to the English page first and then translated. Each translation records the date through which it is synchronized; if it falls behind, retain the older synchronization date rather than implying parity.

Principles

1. Facts, not analysis. Report what sources say. No "why an engineer might care", no competitive positioning, no editorial reads on strategy, founders, or fundraising pace. Anyone can generate analysis; sourced facts are the value here.
2. Every figure carries a source and a date. Numbers go stale fast — "800+ sites" is meaningless without "as of 2026-04". Link the specific page, not the site.
3. Prefer primary sources. Company press releases, product documentation, job postings, and legal/pricing pages beat media coverage and startup databases. Databases are often months behind.
4. Record material conflicts, don't flatten them. Apply the claim-specific source precedence for the current statement, then retain both sides with links when they describe the same scope and period or the difference would materially mislead the reader.
5. Absence is a scoped finding. No tech blog, no published salary bands, no security certification — say what public sources were checked and when, in the Notes section.
6. Apply materiality, not exhaustiveness. Public availability is not by itself a reason to include a fact. Keep information that materially changes the reader's understanding of the product, engineering work, working conditions, business durability, control, regulation, or an important source conflict.

Research protocol

Minimum search scope for absence claims

Before writing that information was not publicly found, complete a reproducible minimum search:

1. Map the official surface: homepage navigation, robots.txt or sitemap where available, company/about, product and documentation, press index, careers, legal pages, blog, and relevant subdomains.
2. Search the current brand, legal name, former names, and product names together with the target topic, in English and the company's relevant local language.
3. Check the authoritative external source for the claim type: corporate or regulatory registers for identity and licences; investor portfolios and funding databases for financing; current and archived job boards for hiring; GitHub organisation, company-name, domain, and product-name searches for open source.
4. Record the search date, names and languages used, and source classes checked. Scope the conclusion as "not found in the reviewed public sources as of YYYY-MM-DD", not "does not exist".

An existing blog or press index does not need every article read before making an unrelated absence claim. Search its index, sitemap, categories, and relevant keywords. A claim that the blog never covers a particular topic requires a correspondingly broader review. Do not search founders' unrelated personal repositories or private accounts merely to support a company-level absence claim.

Source precedence by claim type

Source authority is specific to the claim; there is no single hierarchy for every fact.

Use the most authoritative, specific, and appropriately dated source for the current statement. Keep an older figure as history when it describes a different date. Put a disagreement in Notes when sources purport to describe the same scope and period, or when the difference would materially mislead the reader. A stale database entry does not need equal placement beside a newer primary release unless the conflict itself matters.

Date labels

Use the date that describes the claim, not merely the date on which the page was opened.

If a source has no publication date, write Undated; accessed YYYY-MM-DD. An access date does not make an undated figure current. When the source supplies both publication and measurement dates, retain both.

Page structure

Skeleton to copy for a new company:

# Company Name

> Notes compiled from publicly available sources. Last updated: YYYY-MM-DD.
> Every figure is linked to the source it came from and dated. Verify against primary sources before relying on them.

## TL;DR
## Basic
## Product
## Founder
## Funding
## Engineering
## Notes
## Resources

When a translation exists, add reciprocal language links below the title:

Bilingual terminology

Use these section names consistently. Company-specific subheadings may be added, but should not introduce a new translation for an established term.

What belongs in each section:

TL;DR

One paragraph — what the company is, where, when founded, what the product does — followed by 3–5 bullets carrying the numbers a reader would otherwise have to hunt for: current scale, total funding and latest round, team size, and the one-line engineering summary (main language, cloud, whether the engineering team works in English). Every bullet links its source.

Basic

A table of company facts, each with a source column: current public brand, legal name (local and English), founding date, HQ address, representatives, headcount, engineering-team working language, customer count, assets or scale under management, total raised, and investor list. Describe a company-wide language policy only when the source actually applies company-wide. Add former legal names and former brands when applicable.

Below the table: accelerators, government programs, and awards, each linked and dated. If the company states market or regulatory context in its own releases (policy changes, industry conditions), summarize it here and attribute it as the company's framing rather than as established fact.

Do not collapse different identity concepts into a generic "former name":

• Former legal name — the same legal entity changed its registered name.
• Former brand — the business changed its public brand; legal continuity may or may not be established.
• Trading name / DBA — a commercial name used by a legal entity.
• Predecessor — an earlier company or operation; do not assume it is the same legal entity.
• Related entity — a group, regional, licensed, employing, or settlement entity; it is not an alias.

For a straightforward rename, rows in Basic are enough. When several brands, legal entities, or jurisdictions are involved, add an Identity and legal entities subsection with name, type, jurisdiction, relevant period or status, relationship, and source. Separate confirmed legal continuity, evidence of business or brand continuity, researcher inference, and unresolved relationships.

Product

• What it is and its feature areas — organized the way the docs organize them, linking each area to its documentation page.
• Commercialization — how it is sold: subscription, capacity-based, volume-based, services. Note whether a public price list exists and whether multiple dated versions show the model changing. Keep the structure, skip the individual numbers; the price list is one click away.
• Reported scale over time — a table of representative milestones with dates: the earliest useful baseline, major changes, and the latest figure. Do not reproduce every quarterly or repeated disclosure.
• Announced customers and partners — include material examples that establish a new product, rail, customer segment, geography, concentration, or strategic change. Routine campaigns, exhibitions, repeated deployments, and non-specific MOUs do not need one row each.
• Stated plans — where the company says it is heading, quoted from its own releases (use of funds, targets with deadlines).

Founder

Founders first: role and responsibility split, then a dated career timeline built from interviews and speaker bios. Add other leaders when their remit materially affects product, engineering, operations, finance, hiring, or company control; do not reproduce a full listed-company board or auditor roster by default. Then note what other functions the team page lists (frontend, backend, data science, etc.).

Verifiable career facts only. Don't characterize people, and don't assess whether a founding team is well matched.

Funding

One table: date, round name, amount, investors, cumulative, source. Use the round names the company itself used. Follow with plain facts that don't fit the table — which investor led, repeat participation, investors listed on the company page without a stated round, and any product launch announced alongside a round.

For a listed company, this section may be renamed Capital and financials. Keep pre-IPO rounds and the IPO, a three-to-five-year operating trend, material ownership or control, customer concentration, and meaningful option dilution. Summarize rather than reproduce complete share-issuance ledgers, custody-account shareholder tables, or routine quarterly guidance.

Engineering

• Technology stack and platforms — concrete implementation choices: languages, frameworks, databases, infrastructure, protocols, execution environments, and external platforms, such as Java, InfluxDB, AWS, MQTT, EVM, or Solidity. Label each item as confirmed by documentation or public assets, inferred from hiring, or mentioned only as a hiring requirement. A requirement does not establish current use.
• Systems — what the company actually builds or operates: payment and settlement, real-time dispatch, IoT telemetry, monitoring platforms, data acquisition, forecasting and optimization, on-chain settlement, ERP integration, and similar systems. Give each system a short description and a source. Do not infer a system solely from a preferred qualification.
• Technical background sought — the kinds of work candidates are expected to have done before: observability or monitoring systems, DevOps and platform engineering, financial core systems, high-volume transaction processing, smart-contract security, node infrastructure, or third-party integrations. Keep required and preferred items separate. This is about prior problem experience, not years of employment or a list of technologies.
• Industry domain — the business, regulatory, physical, and economic knowledge behind the work: finance, cross-border payments, energy markets, freight and customs, stablecoin regulation, market mechanisms, contract and subsidy schemes, settlement flows, regulators and filing regimes, or the physics the product models. State whether this background is required, preferred, or explicitly learnable after joining.
• Working conditions — a sourced table: engineering-team working language and the scope of that evidence, location and office policy, remote constraints, visa sponsorship, benefits, salary if published, turnover, whether new graduates or junior engineers are explicitly considered, and any stated expectation about how the team works.

A term can belong to different sections only with a different meaning. For example, on-chain settlement is a system, EVM is a platform, Solidity is a concrete technology, smart-contract auditing is a sought technical background, and stablecoin regulation is industry knowledge. Keep those claims separate and source each one at the appropriate level.

Notes

Grouped into three:

• Not publicly disclosed — engineering blog, open-source presence, salary bands, security certifications, which investor joined which round. Each conclusion states the search date and reviewed public-source scope.
• Inconsistencies across sources — headcount, round naming, cumulative funding, policy statements, targets. Both sides linked.
• Other — anything factual worth flagging that has no home above: business model shifts the company has announced, clusters of related announcements, how much of the product surface is published openly.

Resources

Every source used, grouped as Official (site, company page, press index, careers, documentation with sub-links), Press releases (each with date, newest first), and Third-party coverage and profiles (VC announcements, media, job boards, databases). Mark non-English sources with a language tag.

Special company situations

Listed or disclosure-heavy companies

Regulatory filings make far more information available than an early-stage company page can use. Apply the same engineer-oriented scope rather than treating the filing as a checklist to reproduce. Prefer:

• the latest value plus a three-to-five-year trend for revenue, profitability, headcount, and the operating metric that best explains scale;
• business mix, material customer concentration, control, dilution, development footprint, and disclosed investment in software or infrastructure;
• product, partner, and leadership events only when they change the reader's understanding of the business or engineering work.

Availability is not materiality. Full securities issuance histories, every major shareholder, all outside directors and auditors, routine quarterly figures, and every press release normally remain in the linked filing or press index.

Renames, predecessor brands, and multiple entities

Establish identity before attributing operating facts. Use the current primary brand as the page title and stable directory slug, then record aliases and predecessor names inside the page. For complex cases, put Identity and legal entities near the beginning and include a short dated continuity timeline.

Do not automatically carry a predecessor's funding, customers, licences, headcount, traction, or claims into the current brand. State which brand or entity each historical fact applies to. Evidence such as shared founders, domains, email addresses, backends, hiring, or an explicit "formerly" statement may establish business or brand continuity without proving that the legal entity is the same. Record that distinction once in the identity section and cross-reference it rather than repeating the same caveat throughout the page.

Where to look

1. Official site

Map it before reading anything: the homepage's own links point to the subdomains that carry the substance — documentation, the careers site, the press index, the company/team page. Marketing copy on the landing page is the least useful thing there.

2. Product documentation

If a company publishes docs, this beats every interview and news article. Look for:

Docs sites usually expose a sitemap that lists every page, which is faster than clicking through the navigation.

3. Press releases

Work from the company's own press index rather than search results, and read the release body rather than a summary of it — summaries routinely mangle numbers. Note that a company's own index often lags its newest releases by days or weeks, so also check its page on the distribution service.

Common distribution services:

Chinese companies often have no press index at all. Funding, product and partnership announcements typically appear first as a 首发 article on 36氪, 投资界 or IT桔子, and then on the company's WeChat official account, which has no public archive and cannot be searched from the open web. Treat the 首发 article as the equivalent of a press release — it is usually written from the company's own material — but attribute it to the outlet and its publication date, and say so when the company itself published nothing.

Searching WeChat. Sogou WeChat search is the only general-purpose index of WeChat articles: weixin.sogou.com/weixin?type=2&query=… for articles, type=1 for accounts. The results page returns titles, snippets, the publishing account and a publication date, and is reachable without a login. Two limits, both confirmed on 2026-07-29:

• Its index is partial. Articles that are known to exist — including the two original pieces behind a company's Chinese coverage — may simply not appear. A blank result is not evidence that nothing was published.
• The result links are weixin.sogou.com/link?url=… redirects behind an anti-bot gate; they expire and often will not resolve to the canonical mp.weixin.qq.com/s/… article automatically.

Use it for discovery — which account published what, under which title, on which date, and what other accounts say about the company — and then obtain the permanent mp.weixin.qq.com link before citing. Search the company's Chinese name and its former names, not only the English brand; second-hand articles are often where an unlisted Chinese entity name first surfaces. A snippet alone is an unconfirmed lead, not a source.

4. Job postings

There is rarely a published stack page. Reconstruct it from postings, and mark it as inferred:

• Required vs. preferred is the signal. A required language can support a stack inference; "Kubernetes nice to have" is a hiring-only platform mention, not evidence of production use. Years of experience are not part of the stack.
• Closed postings still count — say so and date them. An older posting accepting "Go or Rust" versus a current one requiring only Go is itself information.
• Postings also carry remote and relocation policy, visa sponsorship, language requirements, equity, benefits, and whether new graduates or junior engineers are considered.

Where to look:

Prefer the company's own page — aggregators paraphrase, and some republish stale listings.

Two cases where a board is the only evidence available:

• English-facing boards (TokyoDev, Japan Dev) publish the details Japanese-language postings often omit — remote and office-day policy, visa sponsorship, the language actually used at work, and sometimes a salary range. Their company profiles are undated and continuously edited, so record them as Undated; accessed YYYY-MM-DD and expect figures such as total funding to lag.
• Community boards (V2EX, Hacker News and similar) are sometimes the only place a company hires publicly, particularly for early-stage teams with no careers page. A posting there may be the sole public description of the stack and working conditions; note who posted it, under which company name, and the thread date, since the name used can differ from the current brand.

Recurring threads such as Ask HN: Who is hiring? and the 谁在招人 board have a property the other boards lack: every entry is written by the company, carries the date of the thread or weekly issue, and stays archived. That turns them into a dated series — comparing a company's entries across issues shows when a stack, a remote policy, or a salary range changed, which is otherwise hard to establish from continuously edited pages. In the ruanyf/weekly case the archive is a git repository, so the published issue that carried an entry is itself dated and diffable.

5. Founders and team

• Company about/company page for current roles and stated backgrounds.
• Long-form interviews, often only in the local language, for career history with dates.
• VC investment announcements — they state the thesis and sometimes the round structure.
• Conference and event speaker bios are surprisingly detailed.
• LinkedIn for role confirmation only.

Keep to verifiable career facts. Don't characterize people.

6. Funding

Build the table from the company's own release for each round, and use the round name the company itself used. Media and databases relabel rounds — pre-Series A reported as Series A is common. Use databases as leads. An outdated cumulative total belongs in Notes only when it purports to cover the same date or would otherwise materially mislead the reader.

7. Other public sources

Databases are useful for finding leads — a round you hadn't seen, an investor name — but confirm every figure against a primary source before it goes on the page.

Cite the original article, not a reprint. General-interest portals and content platforms — Sina, NetEase, Sohu, Tencent News, Baidu Baijiahao, Toutiao, Zhihu columns in Chinese; Infoseek News and regional newspaper sites carrying PR TIMES copy in Japanese — mostly republish other people's work, usually with a 来源 or 転載 line naming the origin. Follow that line and cite the trade publication, the wire release, or the company post it came from. A portal reprint is acceptable only when the original is genuinely gone, and then it should be labelled as a reprint of a named source. Prefer vertical trade media covering the company's own sector over general tech or business outlets: they carry the operational detail national outlets drop.

Two further habits specific to Chinese coverage. First, funding amounts are frequently reported as a band rather than a number — 数千万元, 近亿元, 数亿元 — and the currency is often left implicit; record the phrase as published and the currency only if the source states it, rather than converting a band into a false precision. Second, much of the coverage originates from the company's own material, so several outlets carrying the same figure is one source, not corroboration; trace it back to the earliest 首发 article before treating it as confirmed.

8. Founder and company social media

Use only public professional accounts and only material relevant to the company. Place the fact according to its subject, not its source type: product announcements in Product, hiring statements in Engineering, career history in Founder, financing claims in Funding, and unresolved conflicts in Notes.

Label the attribution, account, post date, and URL. A founder post proves that the founder made the statement; it does not independently confirm the claim. Preserve tense and status: "plans", "targets", "exploring", and "in development" must not become current product facts. Do not use private or access-controlled content, unrelated personal activity, character inference, or personal repositories that are not clearly connected to the company.

Social posts and mutable job pages are fragile sources. Link an existing web archive when available and lawful, but do not require an archive for every source or imply that an unavailable automated fetch means the page is invalid. If a page is human-accessible but blocks automated access, record the access date and limitation. Search-result snippets alone are weak evidence and must be labelled unconfirmed.

Publication and update workflow

Each company page is a dated research snapshot, not a continuously monitored record. The Last updated date is the boundary through which the page's research content was verified, not the filesystem edit date.

A new financing round, rename, major product or regulatory change, or broad engineering refresh normally makes the update material. Companies, source pages, and URLs may change afterward; unrelated repository edits do not require a full recheck.

When a retained source stops working: look for the official replacement URL, then an existing archive, then a source of equivalent authority. Keep an important historical claim with a clear dead-link or archive note when support remains understandable. Remove a claim when it is immaterial and no longer supportable; do not silently replace a primary source with a weaker database entry.

Checklist before publishing

• [ ] Every number has a date and a link to the page it came from
• [ ] Round names match the company's own wording
• [ ] Technology stack items distinguish confirmed use, inference, and hiring-only mentions
• [ ] Hiring requirements are not presented as proof that a system or technology is in production
• [ ] Required and preferred technical or industry backgrounds remain separate
• [ ] Conflicts between sources are listed in Notes, not silently resolved
• [ ] Absence findings state the search date and reviewed public-source scope
• [ ] Source precedence matches the claim type
• [ ] Sources are original articles, not portal reprints, wherever the original exists
• [ ] Undated and mutable sources carry an Accessed date without implying currency
• [ ] Founder or company social posts preserve attribution and aspiration/current status
• [ ] The page applies materiality rather than reproducing every available disclosure
• [ ] Former brands, predecessors, and related legal entities are distinguished when applicable
• [ ] No evaluative language: nothing about whether the company is a good bet
• [ ] At publication, every source link opens and supports the cited statement
• [ ] Last updated date set
• [ ] Translations preserve the same figures, dates, and source links
• [ ] Language links work in both directions
• [ ] Each translation states its synchronization date