BuiltOnJev

What people actually build with Jev, by use case

Most “Jev use cases” pages are a static list someone wrote once. This one is generated from the directory: the counts below move as builds arrive, and every listing behind them was judged by Jev on submission.

Updated September 2026 · 6 min read

The directory right now

19 builds are listed, spread across 4 of 21 use cases. Click a category to see the listings in it.

Use caseBuildsWhat belongs here
Tools & Apps11Standalone developer tools, CLI companions, desktop and web apps
Agents & Browsers6Autonomous agents, browser automation, multi-step tool use on live sites
Games & Real Time1Games, real-time control loops, latency-budgeted decisions
Robotics & Devices1Robot arms, drones, embodied control, on-device inference
Ads & Marketing0Ad creative, campaign copy, marketing content generation
Benchmarks & Evals0Benchmarks, eval harnesses, scoring and model comparison suites
Coding & Code Review0Coding agents, code review, refactoring, PR and repo automation
Context & Memory0Context engineering, memory layers, retrieval that persists across sessions
Documents & OCR0Document parsing, OCR, PDF, form and scanned-page understanding
Ecommerce0Storefronts, catalog and listing work, orders and returns
Inbox & Support0Inbox triage, ticket routing, customer support automation
Open Source0Open-source repos, self-hosted releases, community forks
Routing & Model Choice0Model routing, cost or latency arbitrage, choosing which model serves a request
Sales & Leads0Lead qualification, outbound sequences, outreach automation
SDKs & Integrations0Client SDKs, framework adapters, protocol or provider integrations
Search0Search engines, retrieval, deep research over the open web
Security & Abuse0Security analysis, abuse and fraud detection, prompt-injection defense
SEO & GEO0SEO and GEO — ranking in search results and being cited by AI assistants
Social Feeds0Social posting, feed curation, creator and community workflows
Trading & Markets0Trading bots, backtesting, market monitoring
UI0UI generation, design-to-code, frontend QA

Counts come from this site's own submissions and update as builds arrive. Empty categories are kept visible on purpose — they show what the taxonomy covers, not what has shipped.

Most upvoted builds

Directory order is community upvotes only — never money. The sidebar spotlight is the single paid surface, and it is labeled as such.

How to read the counts honestly

This is a young directory
The taxonomy has 21 use cases because it is aligned one-to-one with a larger directory so the two can be read side by side. A young directory will always have more categories than filled ones. Treat the empty rows as a map of the space, not as a claim about what people build.
  • Counts are listings, not usage. One popular build can outweigh ten experiments. The number tells you what got submitted, not what runs in production.
  • Every listing passed a Jev review for Jev-ness before it counted. whether the link is a Jev build at all the full criteria are here.
  • Categories are assigned by the model, not by the submitter. That keeps them consistent, and it means a mis-filed build is a model error rather than a self-promotion choice.

The canonical list from the vendor

Separately from what is listed here, TypeSafe publishes the categories they see teams deploying Jev into. It is a good checklist when you are deciding whether a decision in your own system is worth extracting:

  • Support triage
  • Content moderation
  • Résumé screening
  • Lead scoring
  • Code-review risk
  • LLM guardrails
  • Data extraction
  • Churn signal

Notice the shape of that list: every item is a small, high-volume judgment that used to be either a brittle rule or an overkill LLM call. None of them are writing tasks. That is the pattern to look for in your own code.

What is deliberately not here

Some categories in the wider Jev conversation have no representation in this directory, and we would rather leave them empty than pad them with filler:

  • Fine-tuning and self-hosting. Jev is a hosted model — there are no weights to fine-tune or run locally. Pages promising otherwise are describing the tooling, not the model.
  • Category pages with nothing in them. We do not generate a landing page per use case until enough real builds exist to justify one. Empty pages are thin content and waste a crawler's budget.
  • Vendor benchmark re-posts. Our eval table lives in one place with its caveat attached, rather than being restated in a new article each week.

Common questions

How many use cases does Jev have?
This directory tracks 21 use cases, assigned by Jev at submission time. The vendor publishes a shorter list of the categories they see teams deploying into, which overlaps but is not identical.
Where does the build data come from?
From submissions to this site. Anyone can submit a link for free; Jev decides whether it is a Jev build and assigns the use case. Counts update as listings arrive.
Why are some categories empty?
Because the taxonomy is broader than the current directory. Empty categories are kept visible as a map of the space rather than hidden, and we do not generate a landing page for one until enough real builds exist to fill it.
Can I filter the directory by use case?
Yes. Every category in the table links to the directory filtered to that use case, and the same filter is available in the sidebar on the home page.

BuiltOnJev is an independent community project, not affiliated with TypeSafe AI. Specs and eval numbers come from TypeSafe's published materials; directory figures come from this site's own submissions and are updated as builds arrive.