Six weeks to launch

Six weeks ago I had an idea. Today it's a live product with real users. fynPrint reads any contract and extracts key terms — parties, dates, payment amounts, termination clauses — using Claude's structured output.

I'm not a lawyer. I'm not an AI researcher. I'm just a developer who got tired of squinting at PDFs. And in six weeks I went from zero to a production app handling real documents.

Here's what worked, what broke, and what I'd do differently.

The problem with raw text extraction

First attempt: dump the entire contract into a prompt and ask for a summary. That's what everyone does. It's also wrong.

Claude would hallucinate clause numbers. It would miss critical dates buried in appendices. One time it told me a 90-page lease had no termination clause — the clause was on page 87.

The fix? Chunk the document intelligently, then prompt for structured output on each chunk. I used a simple sliding window approach: 4000 tokens with 500 token overlap. Each chunk gets a "what's in this section" extraction. Then a second pass merges results.

Structured output is a superpower — but it's finicky

Claude's structured output mode is genuinely useful. You define a JSON schema, and it returns valid JSON every time. No more parsing markdown tables or hoping for consistent formatting.

But here's the catch: the schema needs to be dead simple. I started with a nested object containing arrays of objects with optional fields. Claude would occasionally skip optional fields or nest them wrong.

Lesson: flatten everything. Use a flat list of key-value pairs where the key is a string like "party_name" and the value is the extracted text. Then post-process into a proper structure on your end.

The prompt engineering rabbit hole

I spent two full weeks tweaking prompts. Here's what I learned:

  • Be explicit about what NOT to do. "Do not guess. If you cannot find the exact date, return null." This cut hallucination by 80%.
  • Give examples of bad outputs. Show it a contract snippet and a wrong extraction. Then show the correct one. Claude learns from negative examples surprisingly well.
  • Use system prompt to set the tone. "You are an expert paralegal. Be precise. Cite the exact text you extracted." This made a huge difference.
  • Temperature matters. For structured output, set temperature to 0. I had it at 0.3 initially and got creative interpretations of "termination date."

The cynical take

Let's be real: this isn't magic. It's an LLM doing pattern matching on steroids. For standard contracts — NDAs, service agreements, leases — it works shockingly well. But throw in a weirdly formatted document or a contract with handwritten annotations, and it falls apart.

I've seen demos of AI lawyers that claim 99% accuracy. They're lying. My tool hits about 85% on first pass for clean documents. After user corrections and feedback loops, it gets better. But it's never perfect.

And that's okay. The value isn't perfection — it's speed. A human lawyer takes 30 minutes to find key terms in a 50-page contract. fynPrint does it in 30 seconds. The lawyer still reviews the output, but they're 60x faster.

Real user feedback

I launched on Product Hunt two weeks ago. 300 signups in the first week. Most users are small business owners who can't afford legal review for every contract.

The feedback that hurt: "It missed the renewal auto-renewal clause." That was a bug in my chunking — the clause was split across two chunks and the merge logic failed.

The feedback that helped: "Can you highlight the exact text you extracted?" I added a feature that shows the source text alongside each extracted field. Trust went up immediately.

What I'd do differently

  1. Start with a smaller scope. I tried to extract 50 fields initially. Should have started with 10 and added more as users requested them.
  2. Build feedback loops earlier. Users are great at finding edge cases. I should have added a "report incorrect extraction" button on day one.
  3. Don't over-engineer the PDF parsing. I spent a week on custom PDF parsing. Turns out, a simple text extraction from pdf.js works fine for most contracts. The LLM handles formatting inconsistencies better than I expected.

The future

I'm adding support for scanned documents next. That means OCR before Claude. And I'm experimenting with multi-turn extraction — asking Claude follow-up questions about ambiguous clauses.

Long term, I want to build a contract comparison tool. Upload your standard template and the signed version, and it highlights differences. That's the real value for businesses.

Bottom line (but not that phrase)

Six weeks. One idea. A working product. It's not perfect, but it's useful. And that's more than most side projects ever achieve.

If you're building something with LLMs, my advice: ship fast, listen to users, and don't trust the AI completely. It's a tool, not a lawyer.

P.S. If you want to try fynPrint, it's at fynprint.com. I'm not selling anything — just sharing what I learned.