In Part V you learned how software talks to software. Class 18 asks the next question: what is worth ordering — and where do you find it? Start here: the ByeBuy Data directory. It lists thousands of data sources in one place where a builder can begin discovery instead of guessing which provider exists. This lesson is your map to that map.

See websites differently

Most people see the internet as websites and feeds. A builder learns to see a second internet underneath — registries, records, feeds, archives, time series, and APIs that can be searched, filtered, compared, monitored, and turned into a product.

A weather page tells a person it will rain in Brussels. A weather API hands your app hourly temperature and rain probability as structured fields. A company investor-relations page tells a story. SEC EDGAR hands your app filing history and XBRL facts as JSON. Same internet, different layer — and only the second layer can power software. Thousands of such sources exist, which is why discovery — not guessing — is the skill, and the directory is where it starts.

The eight-category map

Browse the ByeBuy Data directory and you will meet the same eight territories again and again:

Notice the last row. The most valuable data for many products is not public — it is the organization's own records and the user's saved work. The directory covers public ingredients; private layers need permission design (Lesson 18.3).

API, MCP, both, or files — check the access path

Every listing answers "what exists." You must still answer "how does my app touch it":

• API: your app sends a request and receives structured data. Example: the FRED API returns a macro series with observation dates; Open-Meteo returns a forecast for a latitude, longitude, and timezone.
• Both: a documented API plus an MCP server that wraps it for agents.
• Files, exports, or a website: CSV downloads, bulk files, or reports with no live interface. Still valuable — but your workflow becomes download, clean, store, and refresh rather than "call at runtime." A live alert needs a live path; a quarterly report can live on downloaded files.

The directory workflow: question first, vendor second

Work this loop for every idea:

1. Start with a product question, not a vendor. "Which small companies filed strong results while rates fell?" beats "Let's use AI on finance." 2. Browse the relevant category and open several candidates. Note whether each exposes an API, MCP, both, or files/exports. 3. Find the original owner and official docs. The directory is a map; the owner is the territory — EDGAR, FRED, Open-Meteo. 4. Check coverage, price and limits, access method, and fit. Dates, geographies, fields, cost, rate limits, terms — does it answer your question or a neighboring one? 5. Save promising candidates to a source card. Class 19 gives you the five-question scorecard: owner, fields, freshness, rights, failure plan. 6. Choose a small set and name the workflow. One question, one source set, one audience, one output.

What thousands of databases actually let you do

The point is not the directory. The point is that thousands of databases exist about things you already care about — and each one can answer a question no chatbot can answer from memory.

Are house prices in your area rising, and is this listing fair? Start with sold-price registries, assessor records, and licensed listing feeds for your postcode: address, sold date, sold price, bedrooms, square meters, lot, year built. Add current mortgage rates from FRED and the listing's own facts (asking price, days on market, tax history). Normalize them — same currency, same area boundary, same date range — then compute comparables: recent sales of similar size within 2 km in the last 12 months, median price per square meter, premium or discount vs the asking price. The output is not "chat about housing." It is a one-page brief: fair band, three closest comparables with links, and an alert when a new listing lands below band.

Is this used car a fair deal? Combine a permitted vehicle-listings feed (make, model, year, mileage, price, location) with history and cost data: MOT/inspection records, insurance bands, fuel economy, recall notices. The workflow filters to your budget and radius, flags outliers (low price + high mileage + distant seller), and explains the verdict with the three closest comparable listings. Again the product is the shortlist and the reasoning, not a chatbot that "knows cars."

Which local business should I trust? Food-hygiene inspection scores, licensing and permit registers, opening-hours data, plus platform-approved reviews with permission. A neighborhood guide that merges the official score (current, sourced, dated) with what customers actually say — and says which half is which — beats both a star average and a government PDF.

Am I paid fairly, and where do jobs cluster? Public salary surveys, job-posting feeds, and cost-of-living indices by city. Ask "mid-level designer, Lisbon vs Berlin, adjusted for rent" and the app retrieves bands, medians, and posting counts instead of inventing a number. The model explains the tradeoff; the sources supply the figures.

Should I move this trip by a week? An Open-Meteo forecast for exact coordinates and dates, combined with place data, event calendars, and flight or hotel feeds. The model weighs rain probability against price and crowds; the live sources decide the facts.

Is this company actually strong? SEC EDGAR supplies primary-source filing facts, FRED supplies macro context such as rates or inflation, and a licensed market-data feed supplies quotes under a documented price plan. The product hands the model dated facts, a research workflow, and links back to the evidence — never asking it to invent a thesis. That running example, Sonariq, carries through all of Part VI.

What do my own customers keep asking? Approved company documents and permission-appropriate support history. Here the valuable data is the organization's own, and the access boundary is the product — retrieval must respect who may see what before the model ever reads it.

Notice the shape every story shares: one concrete question, two or three named source types, a small amount of normalization and comparison, and one useful output — a brief, an alert, a shortlist, a plan. Nobody built "AI for housing" or "AI for finance." They built one question answered well.

Public does not mean free, open, current, or safe

This distinction saves beginners more pain than any other in this class: public visibility does not mean free, API-accessible, redistributable, current, or safe to automate. Many public records sit behind paid delivery or keys. Some registries publish pages or bulk files with no supported interface. Viewing a record and republishing it are different rights. A filing is authoritative but quarterly; a price is current but needs a licensed feed. And scraping a consumer site because data is visible is fragile and may be prohibited — Class 19 teaches the checks.

The winning idea is rarely "put every source into a chatbot." It is one useful question, one trusted source set, one workflow, and one audience. The directory shows thousands of sources; your product uses a handful.

Practical exercise: build DATA-IDEAS.md

Open the ByeBuy Data directory and create DATA-IDEAS.md with five product questions you care about. For each record: directory category, two candidate listings, original source and docs URL, access path (API, MCP, both, file/export, other), price/free-tier note, benefiting user, and output (report, alert, search, map, recommendation, workflow).

Finish line: DATA-IDEAS.md with five rows, each naming category, two listings, owner, access path, price note, user, and output type.

Verify: pick one row and click through to the owner's official docs. Can you name the endpoint or download? If not, the idea is still a wish.

Check your understanding

1. What is the ByeBuy Data directory for, and why browse it before picking a vendor? 2. What are the four access paths, and which one needs a scheduled refresh instead of a runtime call? 3. Why is "public" not enough to trust a source for production? 4. What makes a data idea "winning" in one sentence?