A conversational legal system that takes someone from nothing to a court-ready divorce filing package in one session.
Jeremy doesn't practice law. He doesn't need to. Ninety percent of what people pay their first divorce attorney for is a guided intake, a document template, and a signature line. Jeremy automates the first two and captures the third in a browser.
Every year, 750,000 New Yorkers file for divorce. The median household income in Brooklyn is $63,000. A $2,500 retainer is not a "divorce fee" — it's a wealth filter. You either have it or you stay married to someone you don't live with anymore.
Jeremy is $19.99. One time. For everything.
Jeremy opens with a splash — his portrait, his name, a single "Start Consultation" button. The user taps in, types an email to save their spot, and the conversation begins. There is no form with 40 required fields. There is no account wizard. It's a chat.
Jeremy asks twelve questions. Name, spouse, addresses, marriage date and place, whether the marriage is broken down, whether there are kids under 21, whether there's property, whether both parties cooperate, phone, residency. Each answer gets extracted by a language model, sanity-checked, and added to a live checklist on the left side of the screen. If someone answers wrong — "we have kids" when asked about children — the system gracefully stops and offers recovery if they meant to say "no."
When the twelfth question clears, the left panel dissolves into a matrix rain overlay. Each intake field scans from VERIFYING to CLEARED ✓, one at a time. A progress bar fills. An ELIGIBLE — AUTHORIZED banner flashes. It's theater, yes — but theater for a reason. At this moment, the user has gone from I'm not sure I can do this to the computer just said I qualify. That transition matters.
Then Jeremy builds the forms. Nine of them, in the order the NY Supreme Court wants them filed. A small animated terminal slides in under each document name, types out the plaintiff's name, the county, the grounds, the caption format, the automatic orders. Thirty seconds per form. A gold "Preview" button appears when it's done.
Some forms need more than the main intake. Before UD-3 (the Affidavit of Service), Jeremy asks nine new questions about the process server — their name, whether they're 18, their address, the date, time, and location of service, how they'll identify the defendant, and a physical description. Before UD-6 (the plaintiff's sworn affidavit), Jeremy asks one question: which of six residency bases applies under DRL §230. Everything else builds from what's already collected.
The system is deliberately simple. Every component does exactly one job, and the seams between them are thin.
A single HTML file at /divorce-intake.html. Holds the chat UI, the avatar, the document roadmap, the 9 JavaScript generators, the watermark injection, the signature cache, the Stripe flow. No framework. No build step. Plain HTML, CSS, and ES6.
A Python HTTP server on an Oracle Cloud VM. Routes /api/chat to Claude, /api/tts to Edge-TTS, /api/sign/* to Pillow, /api/stripe/* to Stripe. No Flask. No FastAPI. Standard library http.server with a threaded mixin.
One SQLite file, data/user_memory.db. Five tables: users, sessions, signatures, sig_tokens, payments. No ORM. Raw SQL, indexed on primary keys, queried through a thin helper.
Every response the user sees is either a static HTML page served off disk, a JSON object from the backend, or an MP3 stream from Edge-TTS. There is no React. There is no Next.js. There is no build pipeline. If the VM burns down, everything can be reconstructed from a single git clone and a pip install pillow anthropic.
Every time the user types a message, the frontend posts to /api/chat with the session ID and the message text. The backend loads the session's intake state from memory, builds a system prompt that tells Claude exactly which field is currently being collected, appends the full message history, and sends it to Anthropic's API.
Claude returns a single JSON object. The message to show the user, the value extracted from their answer (or null if nothing could be extracted), a field_complete flag, an optional stop_trigger, and an optional correction for retroactive edits. The backend parses that JSON, updates the session, marks the field complete if everything checks out, and returns a response to the frontend with the next field queued up.
The system prompt is 3,000 words long. It includes validation rules for each field, stop conditions, the conversational tone (direct, warm, no legal jargon unless explained), and strict JSON format requirements. Claude has been told to accept "12 years" as a valid residency answer and to reject names with profanity in them, even after repeated attempts.
Every divorce filing needs three signatures. The plaintiff signs UD-5, UD-6, UD-9, and UD-12. The process server signs UD-3. The defendant (the spouse) signs UD-7. Collecting those signatures is usually where DIY divorce apps fall apart — someone has to physically be in front of a printer with a pen.
Jeremy handles it differently. After the ninth document builds, he enters a signature intake phase and asks for three email addresses. The backend generates three secure tokens, writes them to the sig_tokens table, and returns three URLs in the form /sign?t=TOKEN. Each party opens their link on any device.
The signature page offers two modes. Draw uses an HTML5 canvas with touch support — the user signs with their finger on a phone. Upload opens the camera or file picker. On submit, the image goes to /api/sign/upload as multipart form data.
Server-side, Pillow runs a five-step pipeline in under a second: fix EXIF rotation (mobile photos come in sideways), convert to grayscale, threshold the dark pixels into an opaque alpha mask, trim the bounding box to the actual ink, pad by ten pixels on each side, and export as a transparent PNG. The result is stored as base64 in the signatures table, keyed by (user_id, role).
The next time the user previews any document, the frontend's sigLine() function checks a signatures cache and injects <img src="data:image/png;base64,..."> above the relevant signature line. The ink lands exactly where it's supposed to, at the correct width, without the user ever needing Photoshop or Adobe Sign.
Until the user pays, every document preview is wrapped in a watermark layer. Dense diagonal "PROSE NETWORK DRAFT" text at 20% opacity, a red outline around every page, and a JavaScript layer that blocks right-click, keyboard shortcuts, print commands, and developer tools. If someone tries to screenshot a preview, a sound effect plays and the page blurs.
When the user clicks "Unlock Filing Package," the frontend posts to /api/stripe/create-checkout. The backend calls Stripe's REST API directly — no SDK, no extra dependencies — and creates a Checkout Session with an inline price: $19.99 USD, "Pro Se Network — Divorce Filing Package." Stripe returns a hosted URL. The browser redirects to Stripe's own domain.
After payment, Stripe redirects back to the app with ?stripe_session_id=cs_xxx in the URL. The frontend detects the parameter on load, posts it to /api/stripe/verify, and the backend calls Stripe's GET endpoint to confirm payment_status === 'paid'. The local payments table gets updated, and the frontend flips userIsPaid to true. The watermark layer never injects again. Clean previews. Clean downloads.
No webhook. No signing secret. The entire verification is a GET request against Stripe's server. It's one round trip, and it cannot be forged by a client — the session ID has to match a pending record in the database, and the payment status has to come back paid from Stripe directly.
The failure mode of every online legal tool is the same. They put 60 fields on a screen and ask the user to know what they mean. Most people have never heard of DRL §230(5) residency. Most people don't know what an Affidavit of Service is or who can sign it. They abandon at field 12 of 60 and pay a lawyer anyway.
Jeremy inverts the failure mode. The user never sees a form. They see a chat. Every question is phrased in plain English by someone who sounds like a friend who happens to know the law. When a question needs context — why am I being asked about my process server's address? — Jeremy explains in one sentence without legal jargon. When the user goes off-script — actually, her address changed — Jeremy handles the correction mid-conversation and updates the checklist.
The forms are a side effect of the conversation. By the time the user finishes talking to Jeremy, the forms are already filled in. They don't know they filled out 9 court documents. They know they answered 22 questions and can now download a PDF.
Jeremy is not a lawyer and does not provide legal advice. Pro Se Network is a document preparation and procedural guidance service. No attorney-client relationship is formed by using this platform. For legal advice specific to your situation, consult a licensed attorney in your jurisdiction. All forms should be verified against nycourts.gov before filing.