Classes 13 through 16 gave you the connection toolkit: you can read an API request and response, guard keys and consent, inspect an MCP server, and choose the smallest useful path for one integration.

Now the question gets bigger. You have a product idea — not one integration, but ten. Do you build all of it yourself?

This lesson replaces that instinct with a better one: break the product into capabilities first, then decide for each one whether to build or connect.

Start with an honest brief

Here is a brief every beginner has written in some form:

It sounds like one project. It is really about ten. Read it slowly and count the hidden jobs:

• People need accounts — sign-up, sign-in, password recovery, sessions.
• Reports need a database — structured storage that survives restarts.
• Files and exports need storage — somewhere uploads and PDFs live.
• The app needs AI analysis — model access that returns structured results.
• Users want email alerts — reliable delivery that does not land in spam.
• Someone has to pay — payments, invoices, and subscription states.
• The whole thing needs deployment — a live URL with preview and production environments.
• It needs a domain — a name people can find and trust.
• You need analytics — to know what is used, what breaks, and what is slow.
• And finally, the reason anyone comes: the unique research logic — what the app knows, ranks, explains, and shows differently from everything else.

That last item is the product. The other nine are the scaffolding that lets the product exist.

Beginners miss this because feature lists hide the work. "Accounts" sounds like a checkbox. In practice it is password hashing, session expiry, email verification, recovery flows, brute-force protection, and support emails from locked-out users. Each capability carries the same surprise: the visible 10 percent, and the invisible 90 percent that keeps it correct and safe.

Differentiated vs. solved infrastructure

For each capability, ask one question:

Differentiated means the customer chose you because of it. Your ranking of companies, your evidence format, your workflow, your curation, your interface. Nobody else offers exactly this.

Solved infrastructure means thousands of competent teams have already built it, documented it, secured it, and operate it at scale. Identity. Password recovery. File uploads. Transactional email. Card payments. DNS. Hosting. Log collection.

Solved does not mean trivial. It means the problem is well understood and a managed service already handles the hard parts — security patches, uptime, edge delivery, fraud checks, compliance paperwork — better than a first-time builder will on a first attempt.

This is the central discipline of the class: spend your scarce building energy on the differentiated core, and connect the rest.

The spectrum: use, connect, compose, build

Build-versus-connect is not two options. It is a spectrum with four stops:

1. Use an existing product manually. No code at all. You send invoices from an existing tool, track early users in a spreadsheet, write research notes by hand. Right for validating an idea before it deserves software.

2. Connect a managed service. Your app calls someone else's running system through an API, an SDK, or an MCP server. Authentication via a provider, payments via a payments service, email via an email API, model answers via OpenRouter. You configure; they operate.

3. Compose a small custom layer around it. You accept the managed service but add your own rules, workflow, data model, or interface on top. The service stores users; your code decides what a "workspace" means. The service sends email; your code decides when an alert is worth sending and what evidence it carries.

4. Build a custom system. You own the whole capability — data model, logic, operations, security, scaling. Sometimes this is the point of the company. Usually it is the most expensive way to get something you could have connected.

Most real products live at stops 2 and 3: connected foundations with a composed layer that makes them feel like one coherent product. Stop 4 is reserved for the part that is actually unique — or for a later chapter, when scale or constraints force your hand.

Do not rebuild auth and payments first

Two capabilities deserve an explicit warning: authentication and payments.

Rebuilding sign-in feels educational until you meet the follow-up work: secure password storage, session rotation, verification and recovery flows, rate limiting, token storage, and the support queue when login breaks. Class 14 showed how much machinery hides behind "Continue with Google." A managed identity service gives you that machinery on day one.

Payments are stricter. Card handling brings fraud, disputes, refunds, subscription state, failed-payment retries, and tax and invoice rules. A bug in a ranking algorithm embarrasses you. A bug in a billing system charges people incorrectly. Connect a managed payments provider first; write your own billing ledger only when you have a reason the provider cannot meet.

The general rule: if a bug in the capability locks users out, loses money, leaks private data, or breaks the law, that is the worst place to learn by building from scratch.

The honest exceptions

Connecting by default does not mean building is never right. There are five intentional exceptions:

• Scale. At very high volume, per-request service pricing or rate limits can exceed the cost of running your own system. But price this on real numbers, not imagined millions.
• Regulation. Some data carries residency, retention, or audit requirements a general service may not satisfy. Check the actual rule before assuming you are the exception.
• Control. You may need behavior the service does not offer: unusual latency, offline operation, or deep integration with internal systems.
• Cost structure. A flat-fee self-hosted component can beat usage-based pricing for steady, predictable workloads — once you include your own operating time in the math.
• Genuinely unique UX. If the sign-in flow, checkout flow, or data layer *is* the product differentiator, owning it is the strategy, not vanity.

Notice the pattern: every exception is specific, measurable, and later. "We will build our own auth at 500,000 users to cut costs" is a plan. "I want to build everything myself" is a hobby — a fine hobby, but not a shipping strategy.

Check your understanding

1. What is the difference between a differentiated capability and solved infrastructure? 2. Name the four stops on the build-versus-connect spectrum. 3. Why are authentication and payments poor first builds? 4. Name two legitimate reasons to build a capability yourself.

Exercise: decompose one idea

Take one product idea — your research app, or anything you actually want to build — and break it into ten capabilities: identity, database, storage, model access, email, payments, deployment, domain, analytics, and your unique logic.

For each one, write use, connect, compose, or build and one sentence explaining why.

Finish line: a ten-row table you can defend out loud. If everything says "build," you have not been honest about which part is unique. In the next lesson you will map each "connect" row to a real service category.

What comes next

You know *what* to connect. Next you need to know *where* — the durable map of service categories every small application draws from, and the recognizable examples that illustrate each one.