DEV Community: Joan A.

I built 3 AI tools around document clarity — now I hope they find the right users

Joan A. — Tue, 24 Mar 2026 20:39:07 +0000

Over the past months, I’ve built three small AI products focused on helping people understand important documents and information more clearly:

GetRevealr.com
WorkContractReview.com
SaferLease.com

They all come from the same idea: people often sign, read, or analyze things that matter without enough clarity, and I wanted to build tools that make that process simpler.

Each one has taught me something different about trust, tone, OCR, and how hard it is to make AI useful in real-world workflows.

Still early, but I’m proud I built all three — and I hope they go well.

What Building an AI Lease Review Tool Taught Me About Clarity, Trust, and Real-World Documents

Joan A. — Tue, 24 Mar 2026 20:31:59 +0000

When people hear about an AI tool for reviewing leases, the first reaction is usually:

“That makes sense. Upload the lease, extract the text, and let the model explain it.”

That sounds simple.

It isn’t.

Building SaferLease.com

has shown me that lease review is one of those products that feels obvious in theory and messy in practice. Because a lease is never just a document. It’s a financial commitment, a legal agreement, and, for most people, something they sign under time pressure.

That changes how you have to build.

Most people don’t want “legal analysis.” They want clarity.

One of the biggest lessons for me has been this:

Most users are not looking for a sophisticated legal essay.

They want to know things like:

What should I pay attention to?
Is there anything unusual here?
What happens if I leave early?
Who is responsible for repairs?
Are there fees, penalties, or clauses that could surprise me later?

That sounds straightforward, but it creates a real product challenge.

If the output is too technical, it becomes hard to use.
If it is too vague, it is not helpful.
If it is too alarming, it creates unnecessary fear.
If it sounds too confident, users may trust things they should verify more carefully.

The right experience is not “AI lawyer mode.”

It is closer to plain-English guidance that helps people spot what matters.

That has shaped a lot of how I think about product quality. In this kind of tool, clarity is not a nice extra. It is the product.

Leases look standardized until you actually work with them

From the outside, lease documents seem fairly repetitive.

But once you start working with real ones, the differences show up fast.

The structure varies.
The wording varies.
The formatting varies.
The risk varies even more.

Some leases are clean and easy to parse. Others are scanned, badly formatted, or full of dense clauses that mix standard terms with highly specific conditions. Two documents can look almost identical while creating very different obligations for the tenant.

That is where a lot of the difficulty lives.

The challenge is not just extracting text or summarizing clauses. The challenge is identifying what deserves attention without overwhelming the user with noise.

Because not every clause is equally important. A routine occupancy rule should not be framed the same way as an automatic renewal clause, a penalty-heavy early termination section, or ambiguous maintenance language.

That weighting matters.

PDF extraction is one of the hardest parts of the stack

A lot of AI products quietly assume that the input text is already clean.

Real users do not behave that way.

They upload scanned leases, exported PDFs, photos turned into PDFs, and documents with inconsistent formatting or missing structure. And when that happens, the extraction layer becomes one of the most important parts of the entire system.

This is where silent failure becomes dangerous.

A clause gets broken across lines.
A number gets misread.
A section heading disappears.
A sentence is merged with the wrong paragraph.

Then the model takes that imperfect text and does what it is designed to do: produce a confident answer.

That means the system can sound polished while reasoning over flawed input.

For me, that has been one of the clearest reminders that OCR and document parsing are not just backend details. They directly affect user trust. If extraction quality is weak, the product has to recognize that and respond carefully rather than pretending everything is fine.

In high-trust workflows, confidence is only useful when it is earned.

Tone is a product decision

Another thing I underestimated early on was how much tone affects perceived quality.

In lease review, users want something that feels calm, clear, and useful. Not robotic. Not alarmist. Not overly academic.

That balance is harder than it looks.

If every clause is presented as a red flag, the output becomes exhausting.
If every clause sounds neutral, important issues disappear into the background.
If the language is too generic, users feel like they learned nothing.

So a lot of the work is really about calibration.

How do you explain risk without overstating it?
How do you surface uncertainty without making the tool feel weak?
How do you keep the experience approachable for someone who has never read a lease carefully before?

That is not just a prompt problem. It is a product problem.

The real goal is reducing uncertainty

What I’ve learned from building SaferLease.com
is that people are not uploading leases because they want a summary for fun.

They upload them because they are uncertain.

They are about to sign something that affects where they live, what they owe, what they are responsible for, and what could go wrong later. They want a faster way to understand the document, but speed alone is not enough.

They want reassurance that they are not missing something important.

That is why I think the real value in this category is not “AI can read your lease.”

It is: AI can help you understand the parts that deserve a second look.

That framing changes everything. It pushes you to optimize less for flashy output and more for practical usefulness.

What Building an AI Contract Review Tool Taught Me About Trust, Tone, and Starting Narrow

Joan A. — Tue, 24 Mar 2026 20:30:17 +0000

When people first hear about an AI tool for reviewing work contracts, the reaction is usually something like:

“That sounds straightforward. Upload a contract, extract the text, ask the model to explain it.”

In practice, it’s not straightforward at all.

Building WorkContractReview.com

has taught me that contract review is one of those product categories that looks simple from the outside, but gets complicated the moment you try to make it reliable for real users.

A contract is not just text. It is risk, context, ambiguity, and user anxiety packed into a PDF.

And that changes everything.

The first lesson: start with one contract type

One of the biggest mistakes you can make when building an AI product is assuming that similar-looking tasks are actually the same task.

At first glance, employment contracts, freelance agreements, NDAs, consulting agreements, and offer letters all feel close enough that a single generalized workflow should handle them.

That assumption breaks fast.

Each document type has different structures, different key clauses, different user expectations, and different levels of risk. The same model prompt that sounds useful on one contract can sound vague, overly cautious, or even misleading on another.

That’s why I think starting narrow matters so much.

Instead of trying to analyze every possible legal document from day one, it makes far more sense to focus on one contract type and get very good at it. Not because expansion is impossible, but because trust is built through consistency. A tool that works well for one use case is more valuable than a tool that kind of works for ten.

In AI products, premature generalization is often just another form of product fragility.

The second lesson: tone is part of the product

Another thing I underestimated early on was how much the tone of the output matters.

With contract review, users do not just want information. They want information delivered in a way that feels clear, grounded, and useful.

Too neutral, and the output feels generic.
Too aggressive, and everything sounds like a legal emergency.
Too much hedging, and users stop trusting the tool.
Too much confidence, and the tool becomes dangerous.

The sweet spot is surprisingly hard to hit.

The best experience is usually not “formal legal robot” and not “casual AI assistant.” It is closer to a knowledgeable friend who helps you understand what deserves attention.

That means the model has to do more than summarize clauses. It has to communicate risk with the right level of weight. A non-compete clause should not sound identical to a probation period clause. A standard confidentiality clause should not trigger the same tone as a one-sided termination condition.

This is where prompt design alone is not enough.

You need iteration, feedback, and a quality loop. You need to read real outputs and ask:

Does this feel trustworthy?
Does this over-warn?
Does this bury the important part?
Would a normal user actually understand what to do next?

In other words, UX writing and model behavior are tightly connected. Tone is not decoration. Tone is product design.

The third lesson: PDF extraction is not a minor detail

A lot of AI product demos begin after the text is already clean.

Real users do not.

They upload scanned PDFs, low-quality exports, phone camera captures, partially corrupted files, and documents with inconsistent formatting. And once that happens, your system is only as good as the text extraction layer underneath it.

This is one of the hardest parts of the stack.

The most dangerous failure mode is not a visible crash. It is silent failure.

The OCR or extraction pipeline mangles a clause.
A heading disappears.
A date is misread.
A salary figure is broken.
A paragraph is split incorrectly.

Then the LLM does exactly what LLMs do: it confidently analyzes the text it received.

That means the model can produce something polished, structured, and persuasive while being grounded in incomplete or distorted input.

This is why I think extraction quality should be treated as a core product problem, not a preprocessing detail.

If the source text is weak, the system should be able to detect uncertainty early, flag it clearly, and avoid pretending the analysis is operating on perfect input.

For users, confidence without reliability is worse than a limitation message.

The real product is trust

What I’ve learned from building WorkContractReview.com
is that AI contract review is not mainly about “making GPT read a contract.”

It is about building a system that users can trust when the stakes feel personal.

And work contracts are personal.

People are not uploading them for curiosity. They are uploading them because they are about to sign something that affects their income, obligations, flexibility, and future options. They want speed, yes. But more than that, they want clarity.

That changes how you build.

You start caring less about showing off model intelligence and more about reducing ambiguity.
You start caring less about covering every document type and more about reliability in the ones you support.
You start caring less about sounding impressive and more about sounding useful.

That shift has probably been the biggest lesson for me.

How I built an AI contract analyzer in a few weeks (and what I learned about legal text)

Joan A. — Mon, 23 Mar 2026 12:07:00 +0000

I'm a developer. I sign freelance contracts. At some point I realized I was doing both badly.
Not the development part — the contract part. I was signing agreements I only half-understood, trusting that the other party had written something reasonable.

So I built GetRevealr to fix that.

The core problem with legal text
Legal language is designed to be precise, not readable. The same clause that protects one party can silently harm the other. The ambiguity isn't accidental — it's structural.

Teaching an AI to surface that ambiguity was harder than I expected. The challenge isn't identifying obviously bad clauses. It's flagging the ones that look neutral but create asymmetric risk — an IP assignment that extends to side projects, a termination clause that only favors one side, an auto-renewal window so short it's nearly impossible to meet.

What the system does

You upload a contract — PDF, Word, or image. The AI reads every clause, assigns a risk score from 0 to 100, and returns plain-English explanations with specific recommended actions for each flagged item.

The hard part was calibrating tone. Legal analysis tends to be either too technical or too alarmist. I wanted something that felt like a knowledgeable friend reading the contract with you — not a legal disclaimer machine.

What I'd do differently

Start with one contract type, not all of them. I built for leases, employment, NDAs, and freelance contracts simultaneously. Each has different risk patterns and different user contexts. Narrowing the scope early would have made the first version much cleaner.

Try it

If you have a contract you've been meaning to read properly, upload it at Getrevealr.com

Free preview, $19 for the full report.

And if you've built something similar or have thoughts on working with legal text — I'd genuinely like to hear it in the comments.