Every Aggregator Is the Same Join Table

Job boards, dating apps, deal sites, flight metasearch, insurance comparison, freelance marketplaces. Different verticals, different vocabularies, wildly different valuations — and underneath, the same three tables and the same argument about which side pays. This started as a simple question ("how do job aggregators make money?") and turned into something more useful: a way to read any aggregator's revenue model off its data model, plus a fairly blunt assessment of which of these are still buildable in 2026, now that the traffic channel most of them were built on is quietly collapsing.

The shape underneath all of them

Start with the job board, because it is the cleanest case. Indeed, ZipRecruiter, SimplyHired — strip the branding away and you get:

-- the entire business, structurally
seekers      -- the free side (supply of attention)
employers    -- the paying side (demand for that attention)
applications -- the join table: the "match" event

Every revenue line is a decision about where on that diagram to put the meter:

• Pay-per-click / pay-per-application. Meter the join event. Indeed's core model, and it is an ad auction in disguise — employers bid per click by job category, exactly like AdWords.
• Sponsored / featured listings. Do not meter the event, meter ranking position. Organic placement is free, top-of-results costs money. SEO vs. SEM, in-house.
• Subscription / SaaS. Meter time rather than events — applicant tracking, bulk posting plans, recruiter seats.
• Resume database access. Sell read access to the supply-side table itself, decoupled from any match ever happening.
• Referral fees. Do not host the listing at all. Aggregate from company career pages, bounce the user back to the source, bill for the bounce.
• Data. Sell the exhaust — anonymized labor-market and salary trends.
• Screening upsells. Background checks, skills assessments; take a markup on somebody else's service.

Yes, it really is a dating site

Swap the two outer tables and you have Tinder. The join table stops being applications and becomes matches, and essentially nothing else changes:

Note what row five is doing. In both cases the listings and profiles are largely user-generated or scraped — the content is not the intellectual property. The ranking engine deciding who gets shown to whom is the product, and it is also the thing they charge you to manipulate. That is not a coincidence; it is the whole design.

Where they diverge: dating apps eventually monetize both sides, job boards almost never do. The reason is inventory. Seeker volume is the thing being sold to employers, so charging seekers would be charging for your own supply. Same logic as Craigslist never billing apartment hunters — only, and only eventually, posters.

Deal aggregators break the pattern, instructively

Slickdeals, RetailMeNot, Honey, DealNews. These get lumped in with marketplaces, but structurally they are something else: an affiliate arbitrage engine with a community layer bolted on for content generation.

user_click → redirect_with_affiliate_id → merchant_site → purchase
                                                     |
                                        postback/pixel → attribution → commission owed

Every deal link is wrapped in an affiliate tracking URL (CJ, Impact, Rakuten Advertising, ShareASale); commission is typically low single digits up to around 10% of sale value, sometimes a flat CPA. Functionally it is the same thing you would build yourself by decorating outbound links with ?ref= and attributing conversions server-side off a merchant webhook.

The structural difference from a job board is on the supply side. Users submit the deals, vote on them, and comment — crowdsourced curation and moderation, unpaid, motivated by reputation. Marginal cost per listing is near zero, versus a job board that has to ingest and normalize structured employer data. That near-zero content acquisition cost is precisely what makes thin affiliate margins viable as the primary revenue line rather than a secondary one.

// conceptually, what runs at checkout
onCheckoutPageLoad(() => {
  tryCouponCodes(knownCodesForMerchant);
  overwriteAffiliateCookie(myAffiliateId); // last-touch attribution wins
});

The wider landscape, sorted by mechanic rather than vertical

Travel metasearch — Kayak, Skyscanner, Trivago

A query fans out to airlines and OTAs in parallel, results get schema-normalized and merge-sorted by price. Architecturally it is fan-out/fan-in against N flaky backends; commercially it is CPC or CPA on the click through to the seller, with a sponsored-placement layer letting airlines buy position independent of price rank.

Insurance and financial comparison — The Zebra, Policygenius, NerdWallet, LendingTree

Pure lead-gen. The user fills a form; the lead is the product, sold to insurers or lenders who compete to convert it. Often a live auction — real-time bidding, but for leads instead of ad impressions. Unit economics are an order of magnitude away from retail affiliate: financial-services CPLs run in tens of dollars, not cents.

Real estate — Zillow, Redfin, Realtor.com

Started as a geo-scoped ad auction (Zillow's Premier Agent: pay for lead flow in your ZIP), then Zillow vertically integrated into iBuying and took on inventory risk directly. That business was wound down in 2021 after the pricing model and the inventory risk failed to line up — a genuinely useful cautionary case study in what happens when a broker of leads decides to become a principal.

Reviews and local — Yelp, TripAdvisor, G2, Capterra

Freemium-for-business: claim your listing free, pay for the enhanced profile, analytics, lead routing, and CPC placement in category results. Historically including, per longstanding complaints, paying to keep competitors' ads off your own page.

Gig and freelance — Upwork, Fiverr, Thumbtack

Take-rate: a percentage of every transaction, the same shape as a payment processor's cut. Thumbtack is the interesting exception — it charges per lead rather than per transaction, because the actual work (fixing the sink) happens off-platform and cannot be metered.

News and content — Google News, Apple News+

Apple News+ is a subscription with revenue split back to publishers. Google News mostly does not monetize directly at all — it is an ecosystem and referral play, not a standalone P&L. Worth noticing that one of the largest aggregators in existence is not run as a business unit.

Compressed into something closer to a function:

revenue_model = f(
  transaction_frequency,     // high-freq (deals, flights) -> ad/affiliate
                             // low-freq (mortgage, insurance) -> lead-gen
  transaction_value,         // low -> volume CPC; high -> CPL/CPA worth real money
  attribution_difficulty,    // trackable click->buy -> affiliate
                             // untrackable (a closing, a repaired sink) -> lead fee or take-rate
  supply_acquisition_cost    // free/UGC supply -> thin margins work at volume
                             // curated/verified supply -> needs subscription to fund it
)

The main branch point is CPL versus CPC/affiliate. Long, high-value, hard-to-track-online sales cycles — insurance, mortgages, real estate, legal, degree programs — converge on lead-gen. Short, trackable, online-completable transactions — retail, travel — converge on affiliate/CPC. You can usually predict which one a given aggregator uses before you look.

So can you build one in 2026?

Here is the part that actually changed, and it is not the part people talk about.

The code has gone to roughly zero marginal cost. That was never the hard part. The hard parts — cold-start liquidity, distribution, trust — are untouched by AI-assisted development, and one of them has gotten materially worse.

Map that onto the architecture. If your funnel is SEO → organic_click → affiliate_redirect → commission, the top of that funnel is shrinking structurally, not cyclically. That is exactly the deal-aggregator and comparison-shopping shape — the models most dependent on informational-intent search traffic, which is the category getting hit hardest.

Model by model:

• SEO-dependent affiliate/CPC aggregators (deal sites, "best X for Y" comparison content) — worst position for a new solo entrant. You are not just outranking Slickdeals; you are competing with an AI Overview that resolves the query before any result gets a click. Incumbents survive on brand-direct traffic and community habit. A fresh clone has neither.
• Lead-gen / CPL (insurance, mortgage, legal, real estate) — structurally more resistant, because "quote my specific situation" still requires the user to hand over personal information in a form, which an AI summary cannot complete for them. But it is the least vibe-codeable category: TCPA compliance, state licensing, carrier and lender agreements. The CRUD app is a weekend. Getting carriers to actually buy your leads is six to eighteen months of business development.
• Marketplace / take-rate (gig, freelance) — cold-start liquidity is unchanged by better tooling. You need supply and demand simultaneously; that is a sales problem wearing an engineering costume.
• UGC-driven aggregators (community boards, niche directories) — the most interesting bucket, for a reason unrelated to AI. Supply is free labor from an engaged community, and the acquisition channel does not have to be Google. Build direct-traffic habits — a newsletter, a Discord, an app people open on purpose — and the zero-click problem largely stops applying to you.

The industry's current answer to zero-click is to optimize for being cited inside AI answers and to treat citation as the visibility metric. That is a reasonable adaptation, but note what it does to the business model: being seen and being clicked have come apart, and citation-only visibility monetizes far worse than a click. Building a revenue model on it is a bet, not a plan.

Where the moat moved

old_moat = time_to_build_MVP   // AI tooling collapsed this toward zero

new_moat = f(
  proprietary_data_feed,               // data nobody else can get
  distribution_independent_of_google,  // community, newsletter, native app
  supply_side_lock_in,                 // why submit HERE and not elsewhere?
  regulatory_barrier                   // unglamorous, but real
)

If you cannot check at least one of those boxes, your build-cost advantage is not an advantage — your competitor has identical tooling on day one. The viable pattern for a bootstrapped build looks like narrow vertical + community-sourced supply + a channel that is not ranking for informational queries. An unglamorous niche the big players will not chase beats trying to out-build Kayak on its own turf, because the constraint was never "can I code this fast enough."

A worked example: the instructional-design job board

Concrete test of the framework. Say you want a job aggregator for instructional design and L&D roles. Check the landscape before speccing anything — and it is not whitespace. Teamed for Learning has run a specialized L&D board since 2017 with several hundred active roles and AI-matched recommendations. Instructional Design Central runs a flat-rate model — a fixed fee for a multi-month listing, no auction anywhere in sight. eLearning Industry, ATD's job bank, the Learning Guild, and IDOL Careers fill out the rest.

Notice what none of them do: run Indeed's per-click bid auction. That is the tell. An ad auction only pays for its own engineering at volume — Indeed can amortize a bidding system across millions of daily queries. A few hundred listings in a niche field cannot. So the correct architecture here is not a bidding engine, it is:

// the entire monetization layer, roughly
listing = {
  employer_id: id,
  expires_at:  now + 6 months,
  status:      'active'   // gated behind a Stripe charge, not a bid
}

Simpler build — which is the point, and also the warning. If the monetization layer is that trivial, technical sophistication was never going to be the moat. Instructional Design Central holds real share running a flat-fee board on an unremarkable stack, because the moat is audience trust, not the checkout flow.

And the ceiling is modest. Total listing volume across the whole field at any moment is in the hundreds; at a realistic per-listing fee and a realistic capture rate against four or five incumbents, this is not a quit-your-job business standalone. Which is exactly how the incumbents treat it — as a traffic and lead-gen layer feeding adjacent products (training, placement services, a media business), not as a pure-play board.

The thing all of this converges on

There is a related argument worth putting next to this one, because it reaches the same conclusion from the opposite direction.

A common claim right now: AI-generated content has become effectively indistinguishable from human work, the viral failure cases are survivorship bias, so worries about marketplaces of human-made digital goods are overblown. On the numbers, incidentally — the widely-quoted "90% of online content will be AI-generated by 2026" figure traces back to a 2022 Europol report citing unnamed experts, with no underlying study. Crawl-based measurements land lower and vary hugely by definition: roughly 74% of recently published pages containing detectable AI content in one large analysis, versus around 38% of business content involving AI assistance at some stage in a narrower one. Directionally up and fast; "almost 100%" is not a measured claim.

But the logic runs backwards. Indistinguishability does not rescue a content marketplace — it is the thing that dissolves it:

if buyer_can_generate(content) is indistinguishable_from(seller_listing):
    marginal_value_of_seller_labor → 0
    price → marginal_cost (~$0)

Even in the world where every generated artifact is flawless, that is worse for the marketplace, not better — because flawless-and-indistinguishable is exactly the condition under which the buyer has no reason to pay you rather than generate their own. A marketplace commission is priced against scarcity, not quality. Infinite interchangeable supply competes price down to the cost of the prompt.

There is a second failure mode too, and it is one engineers should recognize immediately. Detectability at the point of sale is not the same as correctness. A diff can look completely idiomatic, match the surrounding style perfectly, pass a visual review — and still fail on an edge case that only surfaces under test. "Looks human-made" and "is actually correct" are orthogonal axes. The obviously-wrong output is not the dangerous one; the dangerous one is the same error stated more fluently, which sails past a skim-review because it reads well.

Which lands in the same place the aggregator analysis did, approached from the other side. Verification that something is correct and not merely fluent. Curation against a standard. Accountability when it is wrong. A trust relationship that took years to build. Those are the remaining scarce inputs — and every one of them is a human input with a name attached, which is precisely why it cannot be cloned by whoever has the same tooling you do.

This is part of my daily developer log. Follow my journey as I learn new skills and build tools with Brian at Actyra.