How to Build and Deploy a Jev-Powered App

Direct Answer

The practical way to build with Jev is to put it inside ordinary software as a narrow decision layer. Your application collects state, Jev classifies or scores it, and your code decides what to show or do next. A coding agent can build the interface and backend, but Jev is not the part writing the application.

David Ondrej demonstrates that separation by creating Signal, a Typeform-style qualification form. GPT-6 Astra builds the full-stack app. Jev evaluates each submission as highly qualified, qualified, mediocre, or disqualified. GitHub carries the source, Docker packages it, and Coolify deploys it to a Linux VPS.

Access: Jev can be called through TypeSafe's direct API and SDKs or as typesafe-ai/jev through Vercel AI Gateway. Vercel currently labels its free listing as promotional, ending 25 September 2026, so check the live model page before budgeting a production service.

Watch David Build and Deploy the App

Credit and disclosure: this article is based on David Ondrej's build walkthrough, the supplied transcript, and current TypeSafe and Vercel documentation. The VPS section promotes Hostinger and includes David's coupon; hosting claims and plan choices should be treated as sponsored recommendations, not independent benchmarks. Follow David Ondrej on YouTube.

What Jev Does in This Stack

TypeSafe defines Jev as a System One model for fast, structured decisions. It receives shared state and typed questions, then returns values software can consume directly:

• Choice selects one option from criteria supplied by the developer.
• Score places the state on an ordered rubric.
• Noul returns a zero-to-one estimate for whether a statement is true.

Choice and Score include probability distributions and confidence. The official guidance says each question should be atomic: something a knowledgeable person could judge quickly from the supplied context. Multi-factor decisions should be decomposed, then recombined with explicit code.

This means Jev can rank, route, classify, verify, and choose from bounded actions. It does not write arbitrary sentences, explain its reasoning, generate code, or replace a long-horizon model. In David's demo, Astra is the builder; Jev is the decision component.

The Product Idea: An Intelligent Qualification Form

David asks Astra for a Typeform competitor with a 60/40 layout. The left side collects a few answers. The right side exposes the live classification and probability movement so the viewer can see how each answer affects the result.

The first version evaluates fit for a business-automation service. Budget, role, urgency, and stated need move the submission among four labels. That is a reasonable prototype because the output space is small and the decision can remain advisory.

The strongest product version would separate three layers:

1. Evidence: raw answers, source, consent, timestamp, and any derived fields.
2. Judgment: several independent Jev questions with probabilities, not one vague "is this a good lead?" prompt.
3. Policy: code that decides whether to request more information, queue a human review, or trigger a reversible workflow.

That separation makes the system easier to test and change. A sales team can adjust its budget threshold in code without pretending the model learned a new business strategy.

Design the Decision API Before the Interface

The direct TypeSafe quick start uses POST https://api.typesafe.ai/v1/systemone, the model name jev-latest, a shared state, and a map of typed questions. A qualification request can follow this shape:

{
  "model": "jev-latest",
  "state": {
    "role": "Founder",
    "problem": "Manual recruiting and onboarding",
    "budget": "20000_plus",
    "timeline": "this_month"
  },
  "questions": {
    "fit": {
      "type": "choice",
      "instructions": "Classify fit for the defined service",
      "criteria": {
        "high": "Clear problem, authority, budget, and near-term intent",
        "medium": "Real problem but missing one important condition",
        "low": "Early research or weak fit",
        "review": "Insufficient or contradictory evidence"
      }
    },
    "urgency": {
      "type": "score",
      "instructions": "Score implementation urgency",
      "criteria": ["No timeline", "This quarter", "This month"]
    },
    "needs_review": {
      "type": "noul",
      "instructions": "The submission needs a person to clarify it"
    }
  }
}

The example is intentionally conservative. It includes a review option, keeps the questions small, and leaves the final action in code. Do not send API keys to the browser. Call Jev from a server route, validate the request, limit payload size, apply rate limits, and log the model version, criteria version, answer, confidence, and final human outcome.

Build the Application Around the Decision

David starts from an empty folder and asks GPT-6 Astra to research Jev, create the form, expose live probabilities, and prepare the project for Coolify. The first result works but contains too much small helper text, so he asks the agent to simplify the interface.

A more reliable build sequence is:

1. Write the decision contract. Define the state, questions, criteria, confidence policy, and what must always go to review.
2. Create the server boundary. Store the Jev credential only on the server and return a narrow response to the client.
3. Build the form. Validate every field and explain why the information is collected.
4. Persist evidence. Store the original submission separately from model output and later corrections.
5. Add the operator view. Show the decision, probabilities, model and criteria versions, and a manual override.
6. Test before styling deeply. Use labeled examples, contradictory inputs, missing fields, abuse cases, and low-confidence cases.

David also discusses using Jev for adversarial quality checks. That can help rank suspicious or failure-prone states, but the test harness still needs deterministic assertions and human-designed coverage. A classifier clicking around is not a replacement for accessibility checks, integration tests, or security testing.

Deploy the App to a VPS With Coolify

The video uses a Hostinger VPS running Ubuntu 24.04 with a one-click Coolify installation. Coolify connects to a private GitHub repository and builds the app from its Dockerfile. The same architecture works with other Linux hosts or managed container platforms.

1. Create the private repository and push the application.
2. Confirm that .env, keys, local databases, and generated secrets are excluded from Git.
3. Connect only the required repository to Coolify.
4. Select the Dockerfile build pipeline and review the exposed port and health check.
5. Add production secrets in Coolify, including the Jev or gateway key and a strong application-admin credential.
6. Attach persistent storage only for data that must survive a redeploy.
7. Configure a domain and HTTPS, then deploy.
8. Test login, a real submission, a failed API call, a redeploy, and restoration from backup.

The walkthrough correctly keeps the environment file out of Git and revokes an exposed API key. Production should go further: use a secret manager where available, separate preview and production credentials, restrict repository access, protect the admin surface with multi-factor authentication or an identity provider, and never rely on a shared basic password for sensitive data.

The Most Valuable Moment Is the Failed Test

The deployed form accepts an apparently strong submission and still labels it mediocre. David then tries deliberately weak answers: a low budget and "just researching." The result remains mediocre instead of moving to disqualified.

That is not a minor demo glitch. It proves that a working API call and a polished dashboard do not establish decision quality. Astra invented the criteria because the product requirements did not specify them. Jev returned valid structured outputs, but the business logic had not been calibrated.

Before launch, build a reviewed dataset covering clear positives, clear negatives, ambiguous cases, contradictory answers, missing evidence, attempts to game the form, and demographic or linguistic variations that could expose unfair treatment. Compare predictions with reviewer decisions, inspect false positives and false negatives separately, and revise the questions or policy until the error profile is acceptable.

A Production Checklist for Jev-Powered Decisions

• Version everything: model, prompt or instructions, criteria, code policy, and dataset.
• Calibrate confidence: use labeled examples from the real workflow, not a generic threshold copied from a demo.
• Provide an abstain path: medium confidence should request more evidence or route to review; low confidence should not act.
• Limit autonomy by consequence: labels and queue assignment can be reversible; rejection, payment, deletion, or external messages need stronger controls.
• Retain an audit trail: record the supplied state, decision, probability distribution, final action, override, and reviewer reason.
• Protect data: minimize personal information, define retention, encrypt storage and transport, and document subprocessors.
• Measure outcomes: track accepted-result accuracy, false-positive cost, review volume, latency, uptime, drift, and user appeals.

Employment screening deserves special caution. The European Commission identifies systems used to analyse or filter job applications and evaluate candidates as high-risk examples. The US EEOC warns that AI used in recruiting, screening, and hiring can violate employment discrimination law. Treat the video's applicant-scoring variant as a prototype, not a deployment template.

Where This Pattern Can Become a Business

The best opportunities are not "replace every form with AI." Look for an expensive queue where people repeatedly make a small, reviewable decision from well-defined evidence:

• route support requests to the correct team;
• prioritize sales inquiries without discarding the rest;
• score content candidates before editorial review;
• select an agent tool or workflow branch;
• flag records that need a specialist;
• verify whether a generated artifact meets an explicit rubric.

Start with one decision and one reversible action. Measure whether the system reduces handling time without increasing mistakes or unfair outcomes. Only then add more branches, integrations, or automation.

TypeSafe reports Jev was up to 193.6 times faster and 444.6 times cheaper than comparison LLMs in its own workflow evaluations, while also saying those gains are likely at the high end of real-world results. Benchmark the entire product under your own payload sizes, network location, concurrency, review policy, and failure handling.

Video Chapters

• 0:00 - Why Jev is different
• 1:59 - System One decisions and probabilities
• 5:01 - What Jev cannot do
• 6:59 - Speed, cost, and reliability claims
• 12:27 - Choosing a product idea
• 14:58 - Setting up the VPS
• 16:30 - Coolify deployment control panel
• 17:11 - Building Signal with Astra
• 21:10 - Reviewing the first build
• 23:15 - Preparing the deployment
• 25:44 - GitHub, Dockerfile, and secrets
• 29:32 - Testing the live application

Sources and Useful Links

• David Ondrej: Build Anything with Jev, Here's How
• TypeSafe AI: Jev
• TypeSafe documentation: Introduction and primitives
• TypeSafe documentation: API, SDK, and agent quick start
• TypeSafe documentation: Confidence and risk-based thresholds
• TypeSafe: Introducing System One Models and Jev
• Vercel: TypeSafe Jev on AI Gateway
• Vercel AI Gateway: Live Jev model listing
• Coolify: Open-source deployment platform
• European Commission: Navigating the AI Act
• US EEOC: The EEOC's role in AI