I Built an AI Courtroom Simulator with Next.js and OpenAI — Here's the Full Technical Breakdown

Naima Kader — Tue, 04 Aug 2026 05:13:56 +0000

I Built an AI Courtroom Simulator That Lets Law Students Practice Against a Judge, Prosecutor, and Witness — Here's How

When I started building LexAI I had one question: what would happen if you put three AI personas in a courtroom and let a law student argue against all of them simultaneously?

Six weeks later I had my answer — and a production app that law students are actually using.

This is the full technical breakdown of how I built it.

The Problem

Moot court is how law students learn to argue. The problem is brutal:

A professional coach costs $500 per hour
Most law schools offer fewer than 12 practice sessions per year
Students who cannot afford coaching lose more cases
There was no free, intelligent alternative

I am a self-taught developer based in Jijiga, Ethiopia. I have never been to law school. But I recognized a product problem with a clear technical solution — and I built it.

What I Built

LexAI is a full-stack AI courtroom simulator with:

3 AI personas — a strict federal judge, an aggressive prosecutor, and a defensive witness
Real-time argument scoring — every argument rated 0 to 100 on logic, precedent, and persuasiveness
Witness cross-examination with contradiction detection
Session replay timeline showing score progression across every turn
Real-time multiplayer battle mode — two students argue opposite sides simultaneously
Professor dashboard with class management and student analytics
Shareable session cards with dynamic OG image generation on the edge
10 landmark cases including Miranda, Brown v. Board, Roe v. Wade, Apple v. Samsung

Live: lexai-fd92.vercel.app
GitHub: github.com/naimakader/Lexai

The Stack

Next.js 15 App Router
TypeScript
Tailwind CSS
Supabase (PostgreSQL + Realtime)
Clerk Authentication
OpenAI GPT-4o-mini
Vercel OG (Edge Runtime)
Framer Motion

The Hardest Technical Problem — Multi-Persona AI State

The core challenge was keeping three AI personas consistent across a long conversation.

Each persona needed to:

Respond in character without breaking tone
Remember what was said earlier in the session
React to the user's specific argument — not a generic response

My solution was to send the full conversation history to OpenAI on every request with a role-locked system prompt. Each API call includes the complete transcript so the AI has full context.

const prompt = `
You are running a courtroom simulation.

Case facts: ${caseData.facts}

Conversation so far:
${conversation}

Respond with a JSON object with exactly these 5 fields:
- judgeResponse: The judge's response (1-2 sentences, formal)
- prosecutionResponse: The prosecution's counter-argument (aggressive)
- score: 0 to 100 rating the defense's last argument
- scoreDelta: How much the score changed from previous turn
- feedback: One short coaching sentence for the defense

Return only valid JSON. No extra text.
`

Using response_format: { type: "json_object" } on GPT-4o-mini guarantees structured output every time. No parsing failures, no broken JSON.

The Witness Contradiction Detection System

This was the feature that surprised me most technically.

The witness has a prepared testimony. When the user asks questions, the AI tries to stay consistent. But if the user asks a clever question that exposes an inconsistency — the witness stumbles.

The key insight was in the system prompt:

const prompt = `
You are playing the role of a witness in a courtroom cross-examination.

Your original testimony: ${caseData.witness.testimony}

IMPORTANT RULES:
- Stay consistent with your original testimony unless the attorney 
  asks a very clever question that exposes a contradiction
- If caught in a contradiction admit it reluctantly but try to explain it away
- Be evasive and defensive when pressed on weak points
- Never volunteer information the attorney did not ask for

Return a JSON object including:
- witnessResponse: Your answer (1-3 sentences)
- contradiction: true if the attorney caught a contradiction
- score: 0 to 100 rating the question's effectiveness
`

When contradiction: true comes back, a red banner flashes on screen and the score jumps. Users genuinely feel the moment they catch the witness.

Real-Time Multiplayer with Supabase Realtime

The battle mode was the most technically interesting feature to build.

Two players join the same room — one as defense, one as prosecution. Every argument one player makes triggers an AI judge response that both players see simultaneously.

The architecture:

Player 1 creates a room — gets a 6-letter code
Player 2 enters the code — joins as prosecution
When either player submits an argument, the API route calls OpenAI, saves the updated messages to Supabase, and returns the response
Supabase Realtime fires a postgres_changes event to both clients
Both UIs update simultaneously

useEffect(() => {
  const channel = supabase
    .channel(`battle_room_${room.id}`)
    .on(
      "postgres_changes",
      {
        event: "UPDATE",
        schema: "public",
        table: "battle_rooms",
        filter: `id=eq.${room.id}`,
      },
      (payload) => {
        setRoom(payload.new)
      }
    )
    .subscribe()

  return () => {
    supabase.removeChannel(channel)
  }
}, [room.id])

The beauty of this approach is simplicity. I do not need WebSocket servers or complex state synchronization. Supabase handles everything. One database update triggers real-time UI updates across every connected client.

Dynamic OG Images on the Edge

After finishing a session users can share their results on LinkedIn and Twitter. When they paste the link, a dynamic preview image appears showing their score, grade, case name, and best argument.

This uses Vercel's @vercel/og library running on the Edge Runtime:

export const runtime = "edge"

export async function GET(req: NextRequest) {
  const { searchParams } = new URL(req.url)
  const caseTitle = searchParams.get("case") || "State v. Miranda"
  const score = searchParams.get("score") || "0"
  const bestArgument = searchParams.get("best") || ""

  return new ImageResponse(
    <div style={{ background: "#03030A", width: "100%", height: "100%" }}>
      // JSX rendered to a 1200x630 PNG on the edge
    </div>,
    { width: 1200, height: 630 }
  )
}

Every share generates a unique image in milliseconds. No pre-rendering, no storage costs.

The Clerk + Supabase Auth Problem

This was the bug that cost me the most time.

Clerk handles authentication. Supabase handles the database. But Supabase's Row Level Security uses auth.uid() which expects Supabase Auth — not Clerk. So RLS policies blocked all reads and writes even for authenticated users.

The fix was to use the Supabase service role key in all server-side API routes:

// lib/supabase-admin.ts
import { createClient } from "@supabase/supabase-js"

export const supabaseAdmin = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
)

The service role client bypasses RLS. I use it in all API routes where I verify the user via Clerk first, then query Supabase with elevated permissions.

The regular anon client is used only for Supabase Realtime subscriptions on the client side — where I do not need to read or write protected data.

The Session Replay Timeline

After each session, users can replay their entire argument history. Every turn is saved with:

The argument text
The score for that turn
The score delta — how much it went up or down
Whether it was a defense turn or witness turn

This data drives a visual bar chart and a turn-by-turn timeline showing exactly where the user won or lost the case.

const newEntry = {
  turn: (scoreHistory?.length || 0) + 1,
  score: result.score,
  argument: currentInput,
  delta: result.scoreDelta || 0,
  mode: "defense",
}

const updatedHistory = [...(scoreHistory || []), newEntry]

The best argument is calculated on every save:

const bestArgument = updatedHistory.reduce(
  (best, entry) => entry.score > (best?.score ?? 0) ? entry : best,
  updatedHistory[0]
)

Security

Three things I implemented before deploying:

1. Row Level Security on all tables

Even though I use the admin client in API routes, RLS is enabled on all tables as a defense-in-depth measure.

2. Rate limiting

Each user is limited to 50 API calls per hour. This prevents prompt injection attacks and runaway API costs.

3. Input sanitization

All user inputs are limited to 1000 characters before hitting the AI. This prevents prompt injection and keeps costs predictable.

What I Learned

Structured JSON outputs are underrated. Using response_format: { type: "json_object" } eliminated an entire category of bugs. No more regex parsing, no more broken responses, no more try-catch around JSON.parse for normal flow.

Supabase Realtime is genuinely magical. Building multiplayer with WebSockets from scratch would have taken weeks. With Supabase Realtime it took two hours. The postgres_changes subscription is one of the most elegant APIs I have used.

The hardest part of AI products is not the AI. It is the state management around the AI. Keeping conversation history consistent, handling loading states, recovering from errors gracefully — that is where the real engineering work is.

Ship with security from day one. I added RLS and rate limiting before the first deployment. Going back to add security to a running production app is much harder than building it in from the start.

What Is Next

Voice arguments — speak your legal argument instead of typing
AI feedback report — a full written analysis of your performance after each session
More landmark cases — currently at 10, targeting 50 by end of year
Mobile app — React Native version for studying on the go

Try It

Live: lexai-fd92.vercel.app
GitHub: github.com/naimakader/Lexai

If you are a law student, try arguing State v. Miranda. If you are a developer, look at the battle mode and the OG image generation — those are the two parts I am most proud of technically.

Questions welcome in the comments.

Built by Naima — self-taught frontend developer from Jijiga, Ethiopia.

DEV Community: Naima Kader