Built TermsGuard to explain contracts in plain English — looking for feedback
Most people never read the terms they accept. I built TermsGuard to turn contracts, ToS, and privacy policies into plain-English summaries, risk flags, Q&A, and PDFs. The product works — the hard part is whether the pain at “I Agree” is strong enough to change behavior.
Trending on Indie Hackers
After #5, stop. Check back in a day or two — sometimes posting unlocks after a handful of comments. If the same gate is still there tomorrow, leave 3 more and wait. Don’t buy Plus. Don’t post Forge until it lets you.
You already named the real problem in your last line, so I would act on it: nobody pays to feel better about clicking I Agree. The pain only becomes real when someone is personally accountable for the signature, which is a freelancer taking a client contract, an SMB owner signing a vendor MSA, or a founder signing a lease or a SAFE. I would drop consumer ToS entirely and go where the buyer already loses money on bad terms.
The paid product should probably be a decision memo, not a simpler contract. For every flagged clause, show the exact source language, why it matters, what context is missing, the practical question to ask, and the confidence level. Then measure whether the user actually requests a change, rejects a term, or escalates one issue before signing. That behavior is much stronger validation than summary completion because it proves the tool changed a real decision.
The concept makes sense because contracts are usually difficult because of the wording, not because every clause is inherently complicated. Highlighting risky or unusual terms would probably be even more useful than just translating everything into simpler language
Exactly.
Simplifying the language helps, but calling out the risky or unusual terms is what changes the decision. People don’t need every clause rewritten — they need to know what to watch for before they agree.
One trust test I’d add before expanding features is a source-boundary check. Put the same clause through the product in three contexts—a signed contract, a draft under negotiation, and website terms incorporated by reference—and see whether the output clearly separates (1) what the text says, (2) facts the tool cannot know, and (3) questions that depend on governing law or the rest of the agreement. Users may forgive a cautious “this needs context”; they will not forgive a confident answer built on a missing exhibit or undefined term. I’d measure whether people can identify the one unresolved question they should take back to the counterparty after reading the summary. That would test decision quality, not just whether the explanation feels clear.
Really good test.
The dangerous failure isn’t a cautious “needs context.” It’s a confident answer built on a missing exhibit, undefined term, or law the tool can’t know.
Separating (1) what the text says, (2) what can’t be known from this document, and (3) what depends on jurisdiction / the rest of the deal is the right standard.
And measuring whether the user can name one unresolved question for the counterparty tests decision quality, not just readability. That’s a better bar than “does the summary feel clear.”
I would test the trigger before building a browser extension.
Your strongest use cases already arrive as documents: a freelance agreement in email, a lease as a PDF, or a service contract through an e-signing tool. Give a small group a unique address where they can forward the document and receive a decision-focused summary. That removes the need to remember a separate product without committing to a complex integration.
Then watch for one behavior: do they forward a second real document without being reminded? If they do, you have evidence that the trigger and recurring value are both present. Only then would I build the integration around the channel that produced the repeats.
I would also interview each person about the last three contracts they reviewed. Where did each document arrive, what decision were they making, and what did they do when they felt uncertain? The repeated entry point should determine the product surface.
Really practical test.
A forward address matches how the best docs already arrive (email / PDF / e-sign) and removes “open a separate product” friction without a heavy integration.
The signal to watch: do they send a second real document without being nudged? That’s stronger evidence than a one-time try.
And interviewing the last three contracts where they arrived- what decision was at stake, what they did when uncertain is the right way to choose the product surface. Entry point first, integration later.
The "I Agree" friction is real but I think the people who'll actually change behaviour and pay for it aren't the consumer signing up for Spotify. They're the freelancer reviewing a client contract for the first time, the solopreneur signing a supplier NDA before a big deal, the consultant handed a 40-page service agreement with a 24-hour turnaround.
The consumer case is a habit problem. The professional case is a cost problem — getting it wrong has a real dollar figure attached. That's usually where willingness to pay actually lives.
Question: have you tested positioning this toward freelancers and consultants vs a general consumer audience? The use cases look similar from the outside but the sales motion, retention, and what "working" looks like are completely different. A freelancer who signs 5 contracts a month is a recurring user with budget. A consumer who agreed to iCloud terms is probably a one-off.
This distinction is important, and I think you’re right.
Consumer “I Agree” is mostly a habit problem. Freelancer/consultant/solopreneur review is closer to a cost problem: a bad clause has a real dollar or liability downside.
That changes everything: willingness to pay, return frequency, what “working” means.
A freelancer reviewing several client contracts a month is a recurring user with budget. Someone pasting iCloud terms once is usually a one-off.
I haven’t fully split positioning yet, but the stronger early sessions already look more professional: freelance agreements, service contracts, NDAs, leases with something at stake, not casual consumer ToS curiosity.
So the product may serve both, but the business is probably closer to the professional case. Sales motion, retention, and success metrics should be built around that, not around mass consumer “I Agree” moments.
Appreciate you digging more into this.
That read is right — the sessions with something at stake are the ones that matter for the business. Build around freelance agreements and NDAs, let the consumer ToS curiosity show up if it wants, but don't optimize for it.
That's a great breakdown on where the product and marketing effort should be focused - the audience that a stronger need to pay. From a product perspective you won't need to spend time tweaking your analysis for rental agreements, website terms, etc and instead spend that time on the types of agreements the freelancers/consultants etc typically deal with. Focusing on that audience should make your marketing efforts more effective too.
The urgency argument in this thread is right, but I think there's a layer underneath it: even a user with genuine urgency has to remember TermsGuard exists at the exact moment they're staring at an "I Agree" checkbox — and that's usually a standalone tab they'd have to think to open, mid-signup, on someone else's site.
That gap between "I have urgency" and "I have your tool open right now" is probably where most of the drop-off lives, more than the summary quality itself. A lease or freelance contract sits in an email or PDF, so pasting it in later makes sense. But live web ToS/privacy policies — the most habitual "I Agree" moment — happen inline on the page, and by the time someone thinks "let me go check this properly," the friction of leaving the signup flow probably kills most of that intent.
Given your best signal is coming from freelance/lease/service docs people already have in hand, it might be worth treating "documents you paste in" and "pages you're mid-signup on" as two different products with different triggers — one is patient (upload, get a report, decide later), the other needs to intercept the moment itself (extension, inline prompt) or it's competing with someone's impatience to just click through.
Has anyone using it so far caught something before clicking agree, in the moment, versus reviewing a contract they already had?
Agreed, urgency without presence still loses.
Most real “caught something before agreeing” use so far is documents people already had (lease, freelance, service terms). Mid-signup web ToS is different: by the time they leave the flow to open another tool, the intent is often gone.
So paste-and-review and in-the-moment intercept are different products. One can be patient. The other has to show up on the page, or impatience wins.
Makes sense. Given that, would you actually build both, or pick one? My instinct is the paste-and-review side is the safer bet to build out first — it's already proving itself and doesn't require solving distribution (extension installs, in-page permissions) on top of the product itself. The intercept version is probably the bigger opportunity long-term, but also the harder one to get someone to install before they need it.
The product’s hardest question is not whether summaries are useful; it is whether the user has enough urgency to act on one. I’d segment the first cohort by document-triggered intent: a lease, freelance agreement, renewal, or privacy policy all create different decisions and risk tolerance. Then make the output end with one concrete next step, such as “ask for this clause to change” or “compare these two terms,” rather than only a risk score. I’d also track whether users return with a second document or share a question with someone else; that is stronger evidence of recurring value than a one-time upload. Which document type is producing the most specific follow-up questions so far?
Agreed — urgency is more important than merely providing a “useful summary.”
Most specific follow-ups so far have come from freelance agreements, leases, and service terms that include renewal and cancellation language. These situations lead to concrete questions. In contrast, privacy policies generate a high volume of inquiries, but the questions tend to be more general.
It’s more effective to end with a clear next step, such as “ask to change this clause” or “compare these two terms,” rather than just giving a passive risk score. Additionally, return visits and shared questions are the key retention signals that hold more significance than a one-time upload.
The pain question is the right one to be worried about. People know they're signing something they didn't read, and they do it anyway, so the discomfort clearly isn't enough on its own to change behavior.
Where it might flip is when there's a specific decision attached. Nobody reads a social app's terms. But someone about to sign a lease, a freelance contract, or a service agreement with a cancellation clause has an actual thing at stake in that moment. That feels like a different user than "person who wants to be more informed in general."
Are your early users coming in with a specific document they're worried about, or are they mostly just curious and testing it on something random? That split would tell you a lot about which one you're actually building for.
Agreed — that split matters.
Early use suggests the stronger cases are specific documents with something at stake (lease, freelance contract, service agreement, privacy policy before signup). Curiosity runs are weaker: paste something random, skim, leave.
So the product is more “decision support at the document” than “become more informed in general.”
The harder problem is still showing up at that moment. Open to how you’d attack the trigger side.
The “I Agree” moment is a very specific point of friction. Curious what users actually ask TermsGuard about most when they put a real contract through it.
Good question.
In real life, people don’t ask about abstract legal theory. They ask about the decision in front of them:
• Can they sell/share my data?
• Is there auto-renewal or a hard cancellation path?
• What happens to my content/account if I leave?
• Am I giving up the right to sue/forced into arbitration?
• Who is liable if something goes wrong?
The pattern is less “explain the whole contract” and more “tell me what I’m about to agree to that I’ll regret later.”
That’s why the risk flags matter as much as the summary — users want the few points that change the “I Agree” decision, not a full legal brief.
That’s a useful pattern — people seem to care much more about the specific decision risk than understanding the whole contract. I’d be interested in continuing the conversation. If you’re open to it, what’s the best email to reach you at?