This contract looked normal at first glance.
I tested VIDI on a service agreement tied to a multi-million dollar project.
Nothing unusual. Standard structure. Familiar clauses.
But one clause stood out:
It placed full responsibility for unexpected issues on one side - with limited ability to recover costs.
The kind of thing you read and think:
“it’s probably fine”
Until something goes wrong.
And then it’s very expensive.
This is what I keep seeing:
The biggest risks don’t look risky.
They look normal.
People don’t miss them because they didn’t read the contract.
They miss them because they didn’t understand what it actually means.
That’s the gap I’m working on.
Not more analysis.
But helping answer one question before signing:
👉 what could this cost me?
Curious -- have you ever signed something that looked fine, but later caused problems?
This is exactly what I’m building with VIDI.
If you want to try it →
https://joyful-granita-8415bc.netlify.app/index.html
I've been on the wrong end of this in consulting. Had contracts that locked me into specific products or vendors when they didn't need to. Most of the time it was fine, but when I needed to switch tools mid-project it meant renegotiating the contract — extra work, extra tension, all avoidable if the wording had been more flexible from the start.
That's exactly the kind of thing you don't catch until it bites you. Cool concept — the "what could this cost me" framing is the right angle for this.
Yeah, that’s exactly it - looks fine at first, but creates friction later when things need to change.
Appreciate you sharing that.
This is one of the most underserved categories in AI right now — taking something that's traditionally locked behind expensive professionals and making it accessible to the people who actually need it most. Solo founders and small teams are signing contracts all the time (SaaS agreements, vendor deals, partnership terms) and most of us just skim them and hope for the best because $500/hr legal review isn't in the budget.
The "it looks normal" framing is what makes this compelling. It's the same insight we've found building in the AI space — the biggest value isn't in doing something new, it's in catching what humans consistently miss. For contracts that's buried liability clauses; in our world (ad creatives) it's platform-specific requirements that marketers don't realize they're violating until their ads get rejected.
One question: are you thinking about this as a one-time scan tool or something that integrates into the contract workflow (e.g., flagging changes in redlines, or comparing against a company's previously accepted terms)? The latter feels like where the real stickiness would be for repeat users.
Appreciate that - yeah, the “looks normal” part is what keeps coming up over and over.
Right now it’s mainly about helping people catch what they’d otherwise miss before signing.
Interesting parallel with ad creatives as well.
You've identified something that trips up even seasoned founders: the most dangerous contract clauses aren't the ones that look aggressive — they're the ones that look boilerplate. I've seen indemnification clauses buried in "standard" SaaS agreements that essentially made the vendor liable for the client's own regulatory failures, and nobody caught it because it was wrapped in familiar language.
One dimension I'd love to see VIDI tackle is clause interaction — individual clauses often look reasonable in isolation, but the combination of a broad indemnity + uncapped liability + no force majeure can create exposure that's far worse than any single clause suggests. Most contract review (even by lawyers) tends to be linear rather than combinatorial.
Are you thinking about building industry-specific risk benchmarks? For example, what "normal" liability caps look like in SaaS vs. construction vs. consulting? That context would make the risk scoring dramatically more actionable, because a clause that's standard in one industry could be a red flag in another.
That’s a really interesting way to look at it - appreciate you sharing that.
This resonates. I've worked in court recording tech for years, and vendor contracts are a minefield. The "30-day notice" clause hidden in auto-renew sections has burned so many orgs.
One pattern I've seen: they bury data export limitations deep in the MSA. You don't notice until you're trying to leave, then suddenly you're paying $50k for "data migration services" to get your own records out.
Always red-flag clauses that reference "supplemental terms" without showing you those terms upfront.
That’s a great breakdown - especially the auto-renew and data export points, those can get expensive fast.
The “supplemental terms” part is a good one too - easy to miss, but risky.
Appreciate you sharing this. If helpful, feel free to pass it along to others who deal with contracts like this.
This resonates. The thing that cost me the most wasn't a contract clause, it was a whole business structure that looked fine until it wasn't. Lost £1.6m in an ecomm liquidation a few years back. Everything looked solid on the surface. Decent turnover, growing brand, standard agreements. But underneath it was one big single point of failure dressed up as focus. The "it's probably fine" read is exactly right. Nobody questions the normal-looking stuff. That's precisely where the exposure hides. What you're building is solving a real problem, most founders only understand what a clause actually meant after it's cost them something.
That’s a powerful example - and yeah, that’s exactly how it usually happens.
Everything looks fine on the surface, until you understand what it actually means underneath.
Appreciate you sharing that.
This comment was deleted 7 hours ago.
This resonates with me so much. Building something from scratch is equal parts exciting and terrifying. Appreciate you being transparent about the process - it helps the rest of us feel less alone in this journey.
Appreciate that - yeah, it really is both.
Glad it resonates. It can feel pretty isolating at times, so it’s good to know others are going through the same.
IP ownership clause — wording was ambiguous on who owned work created during the contract period vs after. standard template stuff that sounds fine until you actually read it carefully
Yeah, ownership clauses can get tricky fast - especially when it sounds standard at first.
That’s a good catch.
ran a test contract through it last week, flagged a clause I would have missed. the subtle ones are the worst — looks fine until you know what to look for
That’s great to hear - those subtle ones are exactly the ones that slip through.
Curious what kind of clause it was?
This framing is strong. One conversion tweak I'd test immediately: right after the risk explanation, offer a 60-second “before you sign” checklist output (3 bullets + estimated downside band + clause to renegotiate first). That gives users a concrete artifact they can share internally instead of just insight.
If useful, I can do a quick teardown of the current flow and point out where trust/clarity is leaking before the CTA:
https://roastmysite.io/go.php?src=ih_vidi_contractrisk_20260330_1923_hv
Noted
This comment was deleted 15 hours ago.
Will share back once I have run something through it. Interested to see how it handles ambiguous indemnification language specifically -- that is usually where the real exposure hides.
Yeah, that’s exactly where things get subtle.
Curious what stands out once you run something through it.
great post 👏 really helpful
Appreciate it - glad it helped.
That is the right framing -- knowing the downside before signing is what actually changes behavior. Most people only understand the clause after it costs them something. Will give it a try.
Appreciate that - exactly, it’s usually clear only after something goes wrong.
Curious what stands out once you try it.
great post 👏 really helpful
Appreciate it - glad it helped.
this is a great approach. distribution always ends up being harder than building the product itself. i went through something similar with my outreach tools — spent weeks building, then realized nobody could find them. what ended up working was writing about the process on IH. curious what your next distribution move is?
Appreciate you sharing that.
I went through your contract risk summary, and one thing stood out that’s worth paying attention to.
The combination of full responsibility + limited ability to claim unforeseen issues is where most contractors quietly lose money. It’s not obvious at first, but it means if anything unexpected happens, you’re absorbing the cost with very little protection.
A lot of people focus on the contract size, but this part is actually the bigger risk.
One simple thing you might want to check is whether there’s any clause that allows for cost adjustment or renegotiation under specific conditions—if not, that’s where the exposure usually becomes dangerous.
If you want, I can take a deeper look and point out a few specific areas where you might be overexposed. No pressure—just thought I’d share this since it’s a common trap.
Appreciate you sharing that perspective.
Yeah, the clause that costs you is always the one that looked fine at the time. We had a vendor contract for a big data migration -- standard language, limited liability on their side. Project went sideways, costs ballooned, and that clause made it very hard to recover anything.
The "it probably means X" read is where people get burned. What does VIDI actually flag -- the specific clause, or does it model out what the financial exposure could look like?
That’s a great example - and exactly how these situations play out.
Right now it highlights the clause and explains what it means in practice, including where the financial risk can come from.
The goal is to make it clear what the downside could look like before signing - not just what’s written.
This hits very close honestly.
We work with international clients and early on we signed a few contracts without really understanding what we were agreeing to. Everything looked standard. Payment terms, deliverables, IP clause.
One time a client had a clause that basically said any delay from our side for any reason forfeits the milestone payment. We read it. Did not fully understand what it meant practically. Signed.
Project had a delay because client themselves were late with feedback. But clause was worded in a way that put it on us.
Learned a painful lesson that day.
The gap you are describing is real. It is not about reading. It is about understanding what normal looking words actually mean when something goes wrong.
Will try VIDI. Genuinely curious how it handles service agreements with milestone based payment structures 😄
That’s a painful one - and unfortunately pretty common with milestone clauses.
Really appreciate you sharing this.
Curious to hear what stands out when you try it.
Meirambek, is the $6M shown in the screenshot from a real project of yours, or just a test example?
It’s based on a real contract uploaded to the product - details anonymized, of course.
Thanks for clarifying. Makes sense - even seasoned professionals get caught by contracts that look normal. That’s exactly why what you’re building with VIDI is so valuable.
this is actually so true
feels normal when you read it, you just think “yeah yeah standard stuff” and move on
and then later something hits and you’re like wait… what did i even sign
been there myself, it’s not about reading - it’s about actually understanding what it means in real life
Yeah, exactly - that “this looks standard” feeling is where things slip through.
It’s not that people don’t read it, they just don’t pause and question what it actually implies.
Exactly
One thing I didn’t expect while testing this:
Most of these contracts don’t look risky at all.
The issue isn’t hidden clauses - it’s how normal everything feels when you’re reading quickly.
That’s where most mistakes happen.
yeah exactly
that “feels normal” part is the trap
you read it fast, nothing looks scary, so you just move on
and that’s where people get caught without even realizing it
Appreciate that - it’s surprisingly common once you start paying attention to it.
This comment was deleted a day ago.
Appreciate that - still early on my side, mostly focused on understanding the problem deeply right now.