How Indy AI turned more than 35,000 users' feeds into opportunities

In short

I built Indy AI for Contra: a Chrome extension that found freelance work inside people's own LinkedIn and X feeds. It reached more than 35,000 users, found more than 5 million opportunities, and doubled the work available on Contra's marketplace. The discovery ran on each user's own signed-in session, so it grew with the user base rather than with a central infrastructure bill.

Contra needed far more freelance work than it had

Contra is a commission-free freelance marketplace, and it had the classic liquidity problem. Good opportunities pull freelancers in, and active freelancers pull clients in. Contra needed a great deal more of the first, but a central system to go and find that work was not the answer.

Cost was only part of the reason. A central approach would also have thrown away the context of each person's network, and that context is exactly where the relevant work turns up. The opportunities were already appearing in users' feeds, so the browser was the place to start.

Every install did the discovery, so it scaled with the user base

I built the extension around each user's own signed-in session. It looked for opportunities in what that person could already see on LinkedIn and X, which meant there was no central infrastructure to run. Each install behaved as a node, reading content the user was already viewing or could reach. Every new user brought their own network with them, so discovery grew as the user count grew.

The pipeline stayed short. A content script read whichever page the user had open. A background worker handed the sanitised text onward. An LLM analysis step then turned the relevant posts into structured opportunities for Contra's database and threw the rest away.

Nobody had to paste an API key or a cookie

The extension had to work with zero setup, because nobody should have to paste an API key or a cookie before it does anything useful. I used the chrome.webRequest API to watch requests to LinkedIn and X and detect active sessions passively. A successful request to the LinkedIn feed marked the session as active and set off a scan of that feed:

// Simplified logic for session detection
chrome.webRequest.onCompleted.addListener(
  (details) => {
    if (details.url.includes("linkedin.com/feed") && details.statusCode === 200) {
      // We have a valid session
      updateSessionStatus('linkedin', true);

      // Trigger passive scan of the feed content
      injectContentScript(details.tabId);
    }
  },
  { urls: ["*://*.linkedin.com/*"] }
);

What it produced for Contra

Indy AI reached more than 35,000 users, each install a node, and it held a 4.6 out of 5 rating. It doubled the work available on Contra's marketplace, and it was #1 Product of the Week on Product Hunt.

Because those posts came out of real feeds, they carried the context of the networks behind them, including high-intent opportunities that a public search rarely finds. Freelancers got automated job matching, which kept them using it, and the same activity supplied opportunities to the marketplace.

"Doug operated quickly & efficiently, and even proposed ways to improve the feature to exceed our expectations. 10/10!"

Allison Nulty, Head of Product, Contra

Why the browser beat a central system

The distinction that mattered was edge discovery against central collection. The work started in the user's browser, where the access and the social context already existed. Discovery therefore grew with the user base instead of with a bill for central infrastructure.

Frequently asked questions

What did Indy AI do for Contra?

It found freelance work inside the LinkedIn and X feeds that users could already see, and fed the matching posts into Contra's database as structured opportunities. It surfaced more than 5 million opportunities and doubled the work available on Contra's marketplace.

How many people used it?

Indy AI reached more than 35,000 users, with each install acting as a node in the discovery network. It held a 4.6 out of 5 rating and was number one Product of the Week on Product Hunt.

Did users have to hand over credentials?

No. The chrome.webRequest API detected an active LinkedIn or X session passively, so there was no key or cookie to paste. Credentials were read-only, and session cookies were never stored or sent to our servers.

Why build the discovery in the browser instead of a central system?

A central system would have cost more and lost the context of each person's network, which is where the relevant work turns up. The browser already had the access and the social context, so discovery grew with the user base rather than with a bill for central infrastructure.