Kutylawsuit
A platform that prepares demand letters and court documents from user narratives.
- Project
- Our own product
- Our role
- Design · Software development
- Platforms
- Web
01 / Behind the product
A real need. A considered solution.
Challenge
Someone filing a US small-claims case does not know what information to provide first; the 50 states and DC differ in forms, limits and procedure. A document prepared without a lawyer must still fit the official form, with the user’s narrative landing in the right place.
Approach
The user’s plain-language account is captured step by step; reference data for 51 jurisdictions is typed in the repo and document options are resolved per state. Drafts are generated with Gemini, falling back to Claude when the key is absent; PDFs are built client-side with jsPDF. Payment runs through Stripe Checkout with webhook verification, and every integration degrades gracefully without its key. Auth, Postgres and storage are on Supabase with row-level security on. English and Spanish interfaces share one product.
Result
Demand-letter and court-document preparation as an end-to-end web workflow; assistant, case flow, document list and account screens are in the product. Development continues.
02 / Inside the product
The experience, on screen.
Open a screen to explore the details.02 images
03 / Scope & details
The details make the experience.
- 01
Typed reference data for 51 jurisdictions
- 02
Drafting with Gemini, Claude as fallback; jsPDF on the client
- 03
Stripe Checkout with webhook verification
- 04
English and Spanish; Supabase RLS
Technology
nextjs / react / typescript / supabase / stripe
INSIDE THE PRODUCT
The engineering behind the interface.
Systems we built and concrete problems we addressed in this project.
51 jurisdictions, typed
src/lib/data/jurisdictions.ts holds form, limit and procedure data for 50 states and DC; document options resolve per state from it. The schema lives under supabase/migrations, with document content and feedback in separate migrations.
Drafting with a provider fallback
api/generate-document drafts with Gemini and falls back to Claude when GEMINI_API_KEY is absent. The PDF is built client-side with jsPDF; no document body travels to the server for rendering.
Payment verification
api/checkout opens a Stripe Checkout session, api/stripe/webhook verifies the signature and updates the record, and api/verify-payment lets the client poll status; without a key the integration degrades gracefully.
Your idea could be next.
What could we build for you?
From a first release to a growing platform. Let’s plan the design, development and launch together.
From Türkiye to the US, UK, Australia and everywhere in between.