Reading a 10-K as a Developer: The Four Sections That Matter

You are about to build on a company’s API, or you are thinking about owning a slice of one. Either way, the 10-K is the most information-dense primary source available. It is also 150 to 300 pages long. Nobody reads it cover to cover on purpose.

A 10-K is the annual report a US public company files with the Securities and Exchange Commission. The SEC mandates it once per fiscal year; large accelerated filers have 60 days after fiscal year-end to file. You can pull any company’s filing for free on the SEC’s EDGAR system at sec.gov/cgi-bin/browse-edgar. Full-text search works reasonably well; pickuma has a separate post on the SEC EDGAR API if you want to pull these programmatically.

The document is long because it is comprehensive, not because every section is equally useful. Four items will give you 80% of the signal. The rest is either legally required boilerplate or minutiae you only need for specific questions.

The Four Items Worth Your Time

Item 1 — Business

This is the company’s own description of what it does and how it makes money. For a company you already follow closely, you can skim or skip it. For a company that is new to you — especially one whose platform or API you are evaluating — read it carefully.

What to look for: the revenue model (subscription, transaction, usage-based, licensing), the customer segments they prioritize, the competitive positioning they claim, and the geographic footprint. Pay attention to how they describe their dependencies: on cloud providers, on specific hardware, on a handful of large customers, on third-party distribution. A company that casually mentions that two customers represent 40% of revenue in Item 1 is telling you something important.

Developers evaluating a platform should read Item 1 with the question: “What is this company actually optimizing for?” If they describe developers as a growth channel but their primary revenue comes from selling to enterprise procurement departments, that tension is structural — and it tends to show up in how the developer program is resourced over time.

Item 1A — Risk Factors

This section is heavily lawyered. Expect several pages of disclaimers broad enough to cover nearly any outcome. Most of it is defensive boilerplate intended to limit liability, not to communicate genuine management concern.

Read it critically, not credulously. The useful signal is in the specifics that most companies do not include. A risk factor that names a specific regulator, a specific pending legislation, or a specific technology dependency is more informative than one that says the company faces competition or macroeconomic uncertainty. The latter tells you nothing; the former tells you where management is actually worried.

The highest-value exercise: diff the risk factors against the prior year’s filing. EDGAR stores every historical filing, so this is straightforward. Risk factors that are newly added or materially expanded year-over-year often indicate a real change in the operating environment — a regulatory inquiry that began, a customer concentration that grew, a product transition that failed to go smoothly. Removals are also meaningful; a risk that disappeared is either resolved or no longer considered worth disclosing.

Item 7 — Management’s Discussion and Analysis

The MD&A is management explaining the numbers in their own words. It walks through revenue, gross margin, operating expenses, and cash flow year-over-year, with the company’s interpretation of the changes.

This section is useful because it names the specific drivers management wants you to focus on. That framing cuts two ways. If revenue grew 30%, the MD&A will tell you which segment drove that growth, which is legitimately useful context. It will also tend to frame every negative outcome as temporary or non-recurring and every positive outcome as structural — a narrative habit to notice and discount appropriately.

Pay attention to what the MD&A does not explain. If operating expenses grew 40% while revenue grew 20%, and the MD&A covers it in one sentence, that absence is informative. Well-run companies tend to explain their own underperformance with more specificity than companies that are hoping you will not look closely.

The MD&A is also where you will find management’s discussion of liquidity and capital resources — how much cash they have, what credit facilities exist, and whether they see a risk of running short. For earlier-stage public companies, this section can tell you whether a dilutive capital raise is likely before the next fiscal year.

Item 8 — Financial Statements and Notes

The financial statements themselves — income statement, balance sheet, cash flow statement — are the summary. Most of the real accounting detail lives in the notes, which follow immediately after the statements.

The notes are where companies disclose how they recognize revenue (which matters a great deal for software businesses with multi-element contracts), how they account for stock-based compensation, what their lease obligations look like off-balance-sheet, and how they have handled any goodwill impairment from past acquisitions. These choices are material and they differ between companies in the same industry, which makes direct peer comparisons misleading if you ignore them.

For a developer audience: the revenue recognition notes are particularly worth reading for any software or API-based business. ASC 606 requires companies to describe how they identify performance obligations and when they recognize revenue. A company that ships a product on December 31 and recognizes the entire annual subscription fee immediately is doing something different from one that ratably recognizes monthly. The headline revenue number looks the same; the quality is different.

The auditor’s report also lives in Item 8. A clean opinion from a major auditor is table stakes, not a positive signal. What you are actually checking for is any qualification, going-concern language, or internal-control weakness. Those are rare and meaningful when they appear.

How to Move Through the Document

Do not open the filing and start reading from page one. The practical sequence:

1. Read Item 1 if the company is unfamiliar. Skim or skip if you know the business.
2. Read Item 1A, focusing on specific and newly added risks. Use a diff against the prior year.
3. Read Item 7 end-to-end, treating it as management’s testimony — useful but partial.
4. In Item 8, read the revenue recognition and segment notes. Scan the others for anything that looks materially large or unusual.

For most research sessions, this takes 45 to 90 minutes. Everything else in the filing — Item 2 (Properties), Item 3 (Legal Proceedings), the proxy-related items — you read only if a specific question sends you there.

EDGAR’s full-text search lets you jump directly to a section by searching for “Item 1A” or “RISK FACTORS” within the document. The structured financial data — balance sheets, income statements, and cash flows — is also available in machine-readable XBRL format via the EDGAR API, which is useful if you are pulling data programmatically rather than reading manually.