Build your first real project with Jev: a step-by-step walkthrough

Two weeks ago I wrote up what Jev is, what it costs and where TypeSafe says it breaks. The next question arrived on its own: fine, but how do I build something with it that is not a demo? This is that walkthrough - one evening, a gateway key, five typed questions, a coding agent doing the wiring, and a sorter running on your real inbound by the time you go to bed.

Published October 3, 2026 · By Dmitry Tolstoi · 9 min read

What counts as a "real" first project?

In short: real means wired to one live queue you already sort by hand, with the answer driving an action - anything less is a demo.

Watch the public Jev builds and a pattern repeats. Riley Brown had a coding agent make him an inbox app that tagged 500 of his own emails in roughly thirteen seconds. Ryan from the Open Code team pushed 1,700 real emails through it on Greg Isenberg's channel. David Ondrej had GPT-6 Astra assemble a form that scores applicants while they type. Different demos, one shape: a queue of incoming stuff a person used to sort by hand, with a cheap judgement bolted on the front.

So that is what we build: a decision layer in front of your own inbound - the contact form on your site, or your inbox if the form is quiet. The whole spec fits in a sentence. When an item arrives, Jev answers a handful of questions you wrote in advance, the answers get stored next to the item, and the item gets routed by those answers. No chat window, no generated text anywhere. The fancy version can come later; the first project earns its keep by sorting tomorrow morning's queue.

What do you need before you start?

In short: model access through a gateway, a coding agent, a hundred historical items from your own queue, and one free evening.

Four things, and none of them is a programming course.

1. A key that reaches Jev. OpenRouter runs the model behind a dedicated decisions endpoint, and OpenRouter's Jev guide is blunt about the barrier: "There's no waitlist or separate TypeSafe account." The Vercel AI Gateway carries it as typesafe-ai/jev, documented in Vercel's integration guide. TypeSafe's quickstart points direct users at console.typesafe.ai for a first-party key - and if signups there are closed the week you look, either gateway reaches the same model.
2. A coding agent. Claude, Codex, whichever you already run. If you have never managed one, the agentic engineering guide for founders who don't code covers the job - writing briefs and checking results - and this project is a clean first brief.
3. A hundred historical items you own. Old form submissions, an inbox export. They become your measuring stick in step 2.
4. An evening. The on-camera versions of this took their builders minutes to stand up and a while longer to trust. Budget the evening for the trust part.

Step 1: write the questions before any code

In short: three to five questions with fixed answer lists are the actual engineering here - write them before anything else exists.

Jev never improvises. You define every question and every allowed answer up front, and it returns picks with probabilities - the earlier Jev breakdown walks through the three question types in detail. For a lead sorter, my sheet would look like this:

• One Choice - "what is this?" with your own taxonomy as the options: client enquiry, vendor pitch, support request, press, junk. Your categories, your words.
• One Score - urgency on a named rubric, ignore through critical. The docs allow between 2 and 10 levels; five is plenty for a first run.
• Two Nouls - yes-or-no probabilities. "Does the sender want to buy or hire?" and "Is this a scam?" Riley Brown ran that second one across his 500 emails on camera and it flagged 55 of them.

TypeSafe's own documentation gives the design rule: if a question bundles several factors, "decompose it. Ask each factor as a separate question, then combine the results with logic in your code." Keep arithmetic, date windows and counting out of the questions entirely - the vendor's published weakness list says the model "does not count reliably" and "reads dates as text, not as ordered quantities". And write every question the way a stranger reads it, because it "answers the question you wrote, not the one you meant".

Step 2: label a hundred items before the model sees them

In short: your hundred hand-labels are the acceptance test for the whole project - skip them and you end up with a vibe check.

Take the hundred historical items and label them yourself, using exactly the option lists from step 1. It is an hour of dull work, and it is the step everybody skips. The one-evening test I described before is built on it; in a build it earns double wages, because the same hundred labels become the pass-or-fail gate for the finished tool.

The labelling also debugs your answer lists while they are still cheap to change. If you keep hesitating between two categories on your own data, the model will hesitate too - merge them, or split them along the line you actually use when you reply. Fix the list now, in a text file, instead of later in a deployed tool.

Step 3: hand the wiring to a coding agent

In short: you write the brief and hold the key; the agent writes the glue code that pulls items, calls the endpoint and shows a sorted table.

The code in this project is plumbing - fetch items, post them to an API, store the answers, render a table. Coding agents do plumbing well. The brief that produced every public build I listed is some version of this:

Build me a small web tool. It reads new and historical items from [my form's storage, or this CSV export]. For each item it calls Jev through [OpenRouter's decisions endpoint / the Vercel AI Gateway] with these questions and these exact answer lists: [paste your sheet from step 1]. Store every answer with its probability. Show me a table sorted by urgency, filterable by each question. Read TypeSafe's docs before writing code. The API key is in the environment file.

That is the same move Riley Brown showed on camera - a gateway key, a link to the docs, a plain description. David Ondrej took the same route when Astra built his applicant-scoring form against an OpenRouter key, with round trips he clocked at 488 milliseconds live. For direct-key users TypeSafe ships a Python SDK (pip install typesafe-sdk) and an agent skill, so your agent has no excuse to hand-roll requests. Two habits from running agents generally apply unchanged: keep the key out of the code itself, and set a spending cap on the gateway before the first run, not after.

Step 4: run the backlog and count the disagreements

In short: backfill your whole history for cents, then audit every disagreement against your hundred labels before trusting a single route.

First full run: the entire history, not a sample. This is where Jev's pricing changes behaviour - the Ryan demo put 1,700 emails through at 4.2 million input tokens for a reported 18 cents, and at the published $0.042 per million input tokens that arithmetic checks out. Work too expensive to run across your whole archive last month now costs less than the coffee you drink while it runs.

Then the real step: compare the model's answers on your hundred labelled items against your own labels, and read every disagreement. Suspect your wording before the model. Two options that mean nearly the same thing invite coin-flips - merge them. The weakness list admits the model sometimes "leans toward the option that comes first", so reorder a suspect list and rerun; your backfill is cheap enough to do that twice. And trim what you send: accuracy "falls as the state grows with content unrelated to the decision", so the subject and body beat the whole CRM record. The verdict rule from the earlier article still holds - a handful of disagreements in a queue where a mistake costs a minute is a green light, twenty scattered everywhere means this queue is not a classification problem.

Step 5: set thresholds and route - do not decide

In short: split answers into act, ask-me and ignore lanes by probability, and keep anything irreversible in human hands for the first month.

Sort your disagreements by the probability Jev returned and the pattern appears on its own: mistakes cluster at the low end, and your cut-off line draws itself from your own data. TypeSafe's guidance on confidence says the quiet part plainly: "Start with conservative thresholds, test with your own data, and adjust as you observe results." That tuning is your job, by design.

Three lanes work for a first project:

• High probability, routine item - the tool acts: tags, files, pings you about critical items.
• Middle - it queues the item for your eyes.
• Low - a weekly digest.

Whatever the lane, keep money, deletions and replies to real people on the manual side for the first month. One more reason the top lane needs human eyes early: the weakness list warns that content "written to adversarially steer the model" can move the answer. Inbound email is exactly where somebody writes "URGENT" in the subject to jump your queue. Your scam Noul plus a human glance is the antidote.

What does it cost to run, and what do you build second?

In short: at the published rate a form sorter runs for cents a month, so the second project is usually more questions, not more infrastructure.

My own multiplication, on TypeSafe's published price rather than a measurement: a form taking 100 enquiries a day at about a thousand tokens each is 3 million input tokens a month. That is under 13 cents at $0.042 per million, with output tokens free because there are none. Latency is the vendor's claim of 70 to 500 milliseconds, and David Ondrej's live form sat inside that range on camera. In practice the sorter feels instant and costs less than the domain name.

Which is why the second project rarely needs new plumbing. The docs note all three question types "can be mixed in a single API call", so growth is sideways. Add "which of my three services is this about?" to the same request, then point the same five questions at a second queue - comments, DMs, applications. Ryan's clip finder, which scored 17 publishable moments out of one video transcript in about three seconds, is this exact pattern wearing a different hat. One decision layer, many queues.

Where this comes from

Prices, token limits, question-type constraints and endpoint details are from TypeSafe's documentation, Vercel's integration guide and OpenRouter's Jev guide, checked on 3 October 2026, the week this was written. The weakness quotes are from TypeSafe's published model-jaggedness page for jev-1.13. The demo figures are what Riley Brown, Ryan on Greg Isenberg's channel and David Ondrej showed or stated on camera in their September 2026 videos. That list covers the 500 emails in about thirteen seconds, the 55 scam flags, the 1,700 emails for 18 cents, the 488-millisecond round trips and the 17 clip moments. All of those are reported here as their claims, not my measurements. The monthly cost example is my own arithmetic on the published per-token price. I have not run Jev in production yet, and nothing here is a promise about your results.