is it slop?

Don't like the score? Change the rules.

Every point of every score on this site comes from a rule in one file in a public repository. There is no model, no secret weighting, no editorial desk. If a rule is wrong, the fix is a pull request, and it applies to everyone.

How a score is made

  1. 1. Fetch. At grading time the API fetches your landing page or README once, as isitslop-bot. Scripts, styles and code blocks are stripped; what is left is the text a visitor would read.
  2. 2. Run the rules. Each rule in critics.ts gets the text and returns a number between 0 and 1 plus the phrases it matched. Rules have weights. The weighted sum, clamped to 0 to 100, is the Definition score: does it say what it is, why it exists, who it is for, what it is not.
  3. 3. Usage. The owner's self-reported conversion and return rate go through the bands in people.ts. This answers: do the people who find it use it?
  4. 4. Verdict. verdict.ts combines the two halves: both good is Not slop, either bad is Slop, anything else is Mixed. The methodology page is generated from these files.

A rule, in full

This is the real who rule as of v0. It is a regex and a sentence. That is the level of sophistication we are at, on purpose.

{
  id: 'who',
  description:
    'It names who it is for. "For everyone" is for no one. We look for an explicit ' +
    'audience ("for indie developers", "built for clinics", "if you are a landlord").',
  weight: 15,
  run: (_x, lead) => {
    const ev = matches(WHO, lead);
    return { score: clamp01(ev.length / 1.5), evidence: ev };
  },
}

Change a rule in four steps

  1. Fork and clone. git clone https://github.com/jayjaychicago/isitslop.git, then cd api && npm install. The tests need no database and no network.
  2. Edit api/src/heuristics/critics.ts. Add a rule or change one. Write the description for a non-programmer; it appears verbatim on the methodology page. Bump HEURISTICS_VERSION.
  3. Prove it. Add a case to api/test/heuristics.test.ts showing a page that should score differently and why. Run npm test. Try it on real pages with npm run dev and GET /v1/preview?url=….
  4. Open a pull request. Say which kind of page the rule helps and which kind it might hurt. Merged rules deploy to everyone, and old grades keep the version they were computed with.

The one rule about the rules

It must stay self-sustaining. No LLM calls, no paid data vendors, nothing metered per request. The whole service runs on free tiers so that nobody has to pay for it to keep existing and nobody can be pressured by whoever pays. A rule that needs money to run will not be merged, however clever. Everything else is negotiable.

Open problems worth a pull request

  • Verified analytics for the Usage score (GA4, PostHog, Plausible, Stripe) with owner-supplied read-only credentials, so numbers stop being self-reported.
  • Private GitHub repos through a GitHub App or a fine-grained token.
  • Text extraction for JavaScript-rendered landing pages without a headless browser.
  • Rules in languages other than English. Everything in v0 is an English regex.
  • A badge endpoint so owners can show their score in a README.
  • A "why" detector that is smarter than looking for the word "because".

Appeals are the other way in. Every appeal on an entry page is public, and an accepted appeal becomes a rule change. See CONTRIBUTING.md.