What 300+ founders taught me about contracts
Over the past couple of weeks I’ve been building VIDI - an AI tool that helps small businesses understand contract risks before signing.
Earlier I shared the project here on Indie Hackers and the discussions across two posts grew to more than 300 comments.
First discussion:
https://www.indiehackers.com/post/i-built-an-ai-contract-analysis-tool-for-smbs-looking-for-feedback-ae432411d6
Follow-up discussion:
https://www.indiehackers.com/post/what-happened-after-my-ai-contract-tool-post-got-70-comments-e89c3756b5
Reading through all those comments and conversations with founders was incredibly valuable.
Several insights from the community really changed how I think about the product.
For example, @benj_mtn pointed out that founders rarely think in terms of “contract analysis”.
Instead they think about a much simpler question:
“Am I about to sign something that could cost me money later?”
That framing resonated strongly and helped me rethink how the product should be explained.
Another important point from @backendrescue was about trust.
Users need to see exactly where the AI found the risky clause in the contract instead of receiving a black-box answer.
@ShelfCheck also mentioned something that stuck with me - early users often evaluate the founder just as much as the product. Being present in discussions and responding thoughtfully can matter as much as the tool itself in the early days.
Other founders like @Sophia_Dev and @jarv5iz shared really helpful product feedback around things like:
• showing the top risky clauses
• adding suggested edits
• making the workflow clearer (upload → risk highlights → summary)
I also want to say thanks to other community members who shared thoughtful insights and questions in the discussions - including @kintsuai, @nickcoffee, @ourabi, @TaxSort, @JuhyunChoi, @n8nship and @Inatolnato.
Your feedback and perspectives were incredibly helpful while thinking through the product direction.
One thing became very clear from all these discussions.
Many founders told me they usually:
• skim contracts quickly
• rely on templates
• or sign without fully understanding every clause
Especially for things like:
• vendor agreements
• SaaS contracts
• service agreements
Hiring a lawyer for every contract is often too expensive for small businesses.
That’s the problem I’m trying to solve with VIDI.
Right now the product allows you to:
• upload a contract
• detect potentially risky clauses
• get a plain-English explanation
Still very early, but discussions like this are incredibly valuable when building a product from scratch.
If anyone wants to test the current version or share feedback:
https://joyful-granita-8415bc.netlify.app
Curious to hear from the community:
What’s the worst clause you discovered after signing a contract?
that point about how "early users often evaluate the founder just as much as the product" really hits home. when i started asking people to install a tool that literally locks them out of their phone every morning, i quickly realized they weren't trusting my code, they were trusting me not to mess up their device.
building in public completely changes that dynamic because they get a feel for your actual values before handing over deep permissions. besides being active here on ih, how are you planning to build that personal trust with your early adopters?
That's a great point.
One thing I've noticed is that early users often trust the founder before they fully trust the product. So I've been trying to stay very transparent while building VIDI - sharing updates publicly, asking founders about their contract experiences, and incorporating their feedback directly into the product.
A lot of the features I'm adding right now actually come from those conversations. The goal is for people to see how the tool evolves and feel confident about how it works before relying on it for something important like contracts.
Honestly — skim and sign, most of the time. Especially early on when you're moving fast and the contract feels like a formality. The painful lesson comes later when a 90-day termination notice or IP assignment clause actually matters. The reframe to will this cost me money is spot on. That is the real question founders have.
That matches a lot of what I’ve been hearing too.
Many founders say contracts feel like a formality when things are moving fast. The real problems only appear months later when a clause suddenly matters.
That’s actually what pushed me to reframe the product around the question: “Could this cost me money later?” rather than just “contract analysis.”
That reframe is smart. "Could this cost me money later?" is a much more visceral question than "let's review the contract." It maps to how founders actually think — in terms of risk, not process. The founders who get burned are usually the ones who thought the relationship was strong enough that the contract didn't matter. Until it did.
Exactly. A lot of problems seem to appear when the relationship changes and suddenly the contract is the only thing that matters.
That’s usually the moment founders wish they had looked more closely at the terms before signing.
This is a great example of how valuable community feedback can be when building a product. It’s interesting to see how discussions with founders helped shape the direction of the tool.
I recently launched a small Excel-based fantasy football lineup optimizer and I’m also realizing how important early feedback is for improving a product.
Thanks, I appreciate that.
One thing that surprised me while building this is how much product direction can come from conversations with founders. A single comment sometimes reveals a problem you hadn't thought about before.
Good luck with your lineup optimizer as well - building in public and getting feedback early can be really powerful.
The reframing from "contract analysis" to "will this cost me money later?" is the right one. That second question is the actual job-to-be-done - most founders aren't thinking about "risk analysis" as a category, they just want to move fast and not get burned.
To answer your question: the worst clause I've personally encountered post-signing was an automatic liability indemnification buried in a vendor SaaS agreement. Standard boilerplate, easy to miss. Only noticed it when I read the contract again after a billing dispute. The clause was real but the context that made it dangerous - the vendor's data handling practices - wasn't obvious from the contract alone.
What this tells me about VIDI: surfacing the clause with its plain-English explanation is necessary but might not be sufficient. The "why does this matter in practice" context is what actually helps a non-lawyer founder decide whether to push back or accept. The 300-comment validation is strong - the question is whether you can capture enough context to explain not just what the clause says, but what it typically means for a small business.
Good luck with it. The problem is clearly real and you're building in public in exactly the right way.
Really appreciate the detailed perspective - that example is exactly the kind of situation I keep hearing about from founders.
The point about context is especially interesting. Highlighting the clause itself is useful, but understanding why it matters in practice is often what actually helps someone decide whether to push back or accept the terms.
Right now I’m experimenting with explaining not only the clause but also the potential real-world impact for a small business.
Your example with the indemnification clause is a great illustration of how something that looks like standard boilerplate can still carry meaningful risk depending on the situation.
Out of curiosity - do you usually review contracts yourself, or do you sometimes send them to a lawyer first?
The reframing from "contract analysis" to "am I about to
sign something that could cost me money later?" is a really
sharp insight. That's exactly the kind of shift that makes
a product click for users who aren't lawyers.
The trust point around showing where the AI found the risky
clause also resonates — black-box answers are a hard sell
when the stakes are financial. Transparency in the reasoning
seems essential for this category.
As a solo founder myself, I've signed a few vendor agreements
without fully reading them. The worst discovery after the fact
was an auto-renewal clause with a 60-day cancellation window
buried in the middle. Not catastrophic, but a good reminder
that the risky parts are rarely at the top.
Good luck with VIDI — the problem is real and the 300-comment
validation speaks for itself.
Thanks for the thoughtful comment - really appreciate you sharing that example.
The auto-renewal clause you mentioned is exactly the type of thing many founders brought up in the discussions. It’s often buried somewhere in the middle of the document rather than clearly visible.
The trust point you mentioned is also something I’m thinking a lot about. Showing the exact clause and explanation seems important so the output doesn’t feel like a black box.
Still very early, but comments like yours are helping shape how the product evolves.
Nice post—contracts are one of those things founders ignore until it hurts.
One lesson that really stuck with me: clarity beats complexity. A simple, well-written agreement that clearly defines scope, payment terms, IP ownership, and exit conditions saves way more headaches than a long, vague contract.
Also curious—out of everything you’ve seen from those 300+ founders, what’s the most common mistake they keep repeating?
100% agree - clarity beats complexity every time. The best contracts are the ones both sides actually understand.
From 300+ founders the most common mistake I kept seeing: signing auto-renewal clauses without noticing. People get locked into another 12 months and only realize it when they try to cancel.
Second most common - vague scope of work. No clear deliverables, no deadlines, and suddenly both sides have completely different expectations.
Quick update for everyone who joined the discussion earlier.
Over the past few weeks I kept improving the project based on the feedback here. The conversations across these posts actually grew to more than 400 comments, which helped shape several changes in the product.
I recently shared a new update about the progress and what happened during the first 4 weeks of building VIDI.
If anyone is curious about the latest version and how the project is evolving, here’s the update:
https://www.indiehackers.com/post/4-weeks-after-launching-my-ai-contract-tool-trying-to-reach-100-users-b20a107bec
Really appreciate all the insights and feedback from this community.
Signed a contract with an ad agency once. Monthly retainer, or so I thought. Two months in I tried to cancel and they pointed me to a clause buried below the signature line - minimum 3-month term.
Never saw it. Fully my fault.
That's the kind of thing your tool should be screaming about before someone hits sign.
Consider adding highlights for what the contract has hidden.
That’s a really good example.
Clauses like minimum terms or cancellation conditions can be surprisingly easy to miss, especially when they’re placed in unexpected parts of the document.
Appreciate you sharing that experience - stories like this really show how small details in contracts can have bigger consequences later.
The reframe from "contract analysis" to "will this cost me money later?" is one of those product positioning shifts that sounds small but changes everything — it moves the value prop from a feature description to an outcome, which is much easier to justify paying for. The point about trust and showing where the AI found the risk is critical too; the failure mode for most AI legal tools right now isn't accuracy, it's legibility. Users need to see the reasoning, not just the conclusion, especially for anything with financial stakes.
Curious what you found about the moment of contract review in founders' workflows — is the tool being used right before signing, during negotiation, or earlier as a due diligence step? That timing matters a lot for the UX design, because "catching a risk before you sign" and "building a negotiation position" are actually two different jobs with different information needs.
That’s a really interesting point about timing.
From what I’ve seen in conversations with founders, contracts often get attention very late in the process - usually when the agreement is already close to being signed.
At that stage the focus is mostly on quickly understanding whether there’s anything in the structure that could create problems later.
Still learning a lot from these discussions - it’s interesting how differently people approach contract review depending on the situation.
Founders often discover contracts too late because they treat them like someone else’s layer. But the contract is your structure. Trust is human; structure is what the company can actually stand on when goodwill disappears. If the founder doesn’t know that structure cold, the business is basically leaning on vibes — and vibes don’t survive pressure.
That's a really interesting way to put it.
One thing I kept hearing from founders in the Indie Hackers discussions is that many people treat contracts as something that only matters if a dispute happens later.
But by the time that happens, the structure of the agreement is already locked in.
That's actually one of the motivations behind building VIDI - helping founders see those structural risks earlier, before signing.
Exactly.
By the time a dispute appears, the contract stops feeling like paperwork and starts acting like architecture.
That’s why a lot of founders misread the real moment of risk: it isn’t when things break, but when goodwill gets translated into structure.
Once the structure is signed, the company is already standing on it.
That’s a great way to frame it - “goodwill getting translated into structure.”
A lot of founders I’ve spoken with say contracts feel like a formality when things are moving fast. The problem is that the real consequences of those structures often only become visible months later when a clause actually gets triggered.
That’s one of the things I’m trying to surface earlier with VIDI - helping people see how those structural clauses could play out before the agreement is signed.
Hey everyone,
I recently built a small AI tool that scans ecommerce stores and shows where revenue might be leaking (SEO, trust signals, product page persuasion etc).
You can paste any store URL and get a quick audit.
I’d really appreciate some honest feedback from ecommerce founders — does something like this actually help store owners?
Free AI store audit (no signup required):
/storeauditpro.
Interesting idea.
One thing I’ve noticed from talking to founders is that many of them know revenue might be leaking somewhere in their funnel, but they often don’t know where to start looking.
A quick automated audit that highlights things like trust signals, SEO issues, or product page clarity could definitely help narrow down the problem.
The key question is probably how actionable the insights are - if the tool can clearly show what to fix and why it matters for conversions, I could see it being useful for early-stage ecommerce founders.
Curious to test it on a couple of stores.
Thanks, that’s exactly the problem I noticed too.
A lot of founders know something is off in their funnel, but it’s hard to quickly identify where the biggest leaks are.
Right now the tool tries to highlight things like missing trust signals, weak product page persuasion, SEO issues, etc.
If you’re open to it, feel free to drop a store URL here — I’d be curious to run an audit and see what it finds.
Makes sense.
Another interesting angle might be connecting the audit to specific actions - for example “adding trust signals here could improve conversions” or “this product page might need clearer value messaging.”
That kind of concrete guidance would probably make the audit much more useful for early stage store owners.
Good point.
Right now the tool focuses on identifying the biggest leaks in the store (SEO, trust signals, product page clarity etc).
But adding more concrete recommendations like “add trust badges near checkout” or “strengthen value messaging here” is something I'm working toward.
Appreciate the feedback!
That sounds like a good direction.
Turning the audit into concrete suggestions like that would probably make it much more valuable for store owners who just want to quickly fix the biggest issues.
Curious to see how it evolves.
Appreciate that!
Yeah, the goal is to move from just identifying issues to giving clearer “next actions” for store owners.
Something like: fix this section, add these trust signals, improve this product messaging, etc.
Still early but that’s definitely the direction I'm heading.
Thanks for the feedback!
The contract problem is real but rarely discussed in the indie hacker space. Most solo founders ship on a handshake and regret it once money is involved. 300 data points is solid — what was the most common mistake?
Good question.
One pattern that showed up a lot in the discussions was founders signing agreements that looked “standard” but had clauses that heavily favored the other party — especially around termination, auto-renewal, and exclusivity.
Many founders mentioned they only discovered the risk months later when something actually went wrong.
That moment - realizing a clause you signed months ago now has real consequences - is exactly the situation I’m trying to prevent with VIDI.
Contract review is one of the best AI use cases because the downside of missing a bad clause is huge but the cost of lawyer review for every contract is prohibitive for small businesses. Smart to position it as risk detection rather than legal advice — keeps the liability clean.
Exactly - that was one of the important insights while building this.
The goal isn’t to replace lawyers, but to help founders quickly spot potential risks before signing.
For many small businesses the real problem isn’t drafting contracts - it’s understanding whether a clause could create problems later.
So positioning it around risk detection felt like the most practical and honest approach.
This level of detail is exactly what makes IH valuable. The revenue breakdown helps set realistic expectations. Would love a follow-up post on what you'd do differently with what you know now.
That’s a great idea.
Looking back, one thing I would probably do differently is focus earlier on the exact moment when someone is about to sign a contract.
A lot of founders don’t think about “contract analysis” - they just want a quick answer to the question: “Is there anything here that could cause problems later?”
I’m planning to write a follow-up post once more founders test the tool with real agreements.
glad the trust point resonated with people - seeing it show up in the write-up alongside the other insights from the community is a good sign that the discussion was genuinely useful. the "moment before signing" framing that emerged from all of this is the clearest example of how a comment thread can do real product research
Thanks - that insight about the “moment before signing” really stuck with me.
It shifted how I think about the product. Instead of positioning VIDI as “contract analysis”, I'm trying to focus on that specific decision moment when someone is about to sign and quickly wants to understand the risk.
The Indie Hackers discussion was honestly one of the most useful sources of product feedback so far. It helped shape both the messaging and some of the features I'm building now.
that pivot from "contract analysis" to owning the specific moment before signing is exactly the kind of clarity that comes from real conversations - good luck with the build
Appreciate that, thanks.
Those conversations definitely helped clarify where the real value might be for founders. It's been really interesting seeing how much insight can come just from discussing the problem openly with other builders here.
Great information.
Thanks! Yeah that framing shift made a big difference. The Indie Hackers discussion actually helped surface that insight.
The reframing point is huge. I've noticed this with my own SaaS — when I describe what the tool does people nod politely, but when I describe the specific painful moment they're in when they need it (like sitting there at 11pm trying to figure out if a contract clause is going to screw them) suddenly they get it. Sounds like the community basically handed you your marketing angle for free which is pretty cool.
Yeah exactly - describing the specific moment someone feels the risk seems to resonate much more than describing the tool itself.
The Indie Hackers discussion actually helped surface that framing.
The reframe from "contract analysis" to "am I about to sign something that could cost me money later?" is a masterclass in product messaging. Most technical founders (myself included) describe their tools in terms of what the tool does, not what the user fears. That single insight from @benj_mtn is worth more than any landing page A/B test. Really appreciate you sharing these lessons publicly instead of keeping them as internal notes.
Appreciate that. I’ve realized the same thing - describing what the tool does is much easier than describing the decision moment the user is actually facing.
That framing shift changed how I think about the product.
This is a solid write-up, and the insight about framing (“am I about to sign something that could cost me money later?”) is exactly how most founders actually think. People rarely search for “contract analysis,” they just want to know if they’re about to sign something that could come back and hurt them financially.
One thing I’ve seen repeatedly though is that the real pain often isn’t understanding the clause itself, it’s knowing what to do next once you spot something risky. A lot of founders can identify that something feels off, but then they get stuck wondering whether the clause is normal, whether it’s aggressive, and what they should actually ask the other party to change.
That’s where a big layer of value could come in: turning analysis into decision support. For example, instead of just highlighting a risky termination clause, the product could also suggest a reasonable negotiation edit or alternative wording founders could send back. Something like: “This clause locks you in for 12 months suggested edit: add a 30-day termination for convenience.” That bridges the gap between understanding and action.
I also completely agree with the trust point. Showing the exact clause with the highlighted text is essential. When legal and financial risk is involved, founders are naturally skeptical of black-box answers, so transparency is a big part of adoption.
Another interesting direction over time could be building a benchmark library of founder-friendly clauses across common agreements (SaaS, vendor, services, etc.). Over time that dataset could become extremely valuable, because founders wouldn’t just see “this is risky,” they could also see how their contract compares to what’s typically considered fair.
Really thoughtful points - especially the gap between “this feels risky” and “what should I actually do about it.”
That step from analysis to decision support is something I’ve been thinking about a lot. Highlighting the clause is useful, but helping founders understand what a reasonable change could look like is where the tool can become much more actionable.
The benchmark idea is also interesting. Over time it would be powerful if founders could see not only that something is risky, but how it compares to what’s typically considered fair in similar agreements.
Appreciate you sharing these ideas - this is exactly the kind of feedback that helps shape the product.
We are looking for someone who can lend our holding company 300,000 US dollars.
We are looking for an investor who can lend our holding company 300,000 US dollars.
We are looking for an investor who can invest 300,000 US dollars in our holding company.
With the 300,000 US dollars you will lend to our holding company, we will develop a multi-functional device that can both heat and cool, also has a cooking function, and provides more efficient cooling and heating than an air conditioner.
With your investment of 300,000 US dollars in our holding company, we will produce a multi-functional device that will attract a great deal of interest from people.
With the device we're developing, people will be able to heat or cool their rooms more effectively, and thanks to its built-in stove feature, they'll be able to cook whatever they want right where they're sitting.
People generally prefer multi-functional devices. The device we will produce will have 3 functions, which will encourage people to buy even more.
The device we will produce will be able to easily heat and cool an area of 45 square meters, and its hob will be able to cook at temperatures up to 900 degrees Celsius.
If you invest in this project, you will also greatly profit.
Additionally, the device we will be making will also have a remote control feature. Thanks to remote control, customers who purchase the device will be able to turn it on and off remotely via the mobile application.
Thanks to the wireless feature of our device, people can turn it on and heat or cool their rooms whenever they want, even when they are not at home.
How will we manufacture the device?
We will have the device manufactured by electronics companies in India, thus reducing labor costs to zero and producing the device more cheaply.
Today, India is a technologically advanced country, and since they produce both inexpensive and robust technological products, we will manufacture in India.
So how will we market our product?
We will produce 2000 units of our product. The production cost, warehousing costs, and taxes for 2000 units will amount to 240,000 US dollars.
We will use the remaining 60,000 US dollars for marketing. By marketing, we will reach a larger audience, which means more sales.
We will sell each of the devices we produce for 3100 US dollars. Because our product is long-lasting and more multifunctional than an air conditioner, people will easily buy it.
Since 2000 units is a small initial quantity, they will all be sold easily. From these 2000 units, we will have earned a total of 6,200,000 US dollars.
By selling our product to electronics retailers and advertising on social media platforms in many countries such as Facebook, Instagram, and YouTube, we will increase our audience. An increased audience means more sales.
Our device will take 2 months to produce, and in those 2 months we will have sold 2000 units. On average, we will have earned 6,200,000 US dollars within 5 months.
So what will your earnings be?
You will lend our holding company 300,000 US dollars and you will receive your money back as 950,000 US dollars on November 27, 2026.
You will invest 300,000 US dollars in our holding company, and on November 27, 2026, I will return your money to you as 950,000 US dollars.
You will receive your money back as 950,000 US dollars on November 27, 2026.
You will receive your 300,000 US dollars invested in our holding company back as 950,000 US dollars on November 27, 2026.
We will refund your money on 27/11/2026.
To learn how you can lend USD 300,000 to our holding company and to receive detailed information, please contact me by sending a message to my Telegram username or Signal contact number listed below. I will be happy to provide you with full details.
To learn how you can invest 300,000 US dollars in our holding, and to get detailed information, please send a message to my Telegram username or Signal contact number below. I will provide you with detailed information.
To get detailed information, please send a message to my Telegram username or Signal username below.
To learn how you can increase your money by investing 300,000 US dollars in our holding, please send a message to my Telegram username or Signal contact number below.
Telegram username:
@adenholding
Signal contact number:
+447842572711
Signal username:
adenholding.88
This discussion is about AI tools for understanding contract risks. Investment solicitations like this are not related to the topic here.
Please keep comments relevant to the discussion.
While the website is highly promising, an insightful critique must address the inherent nature of the product. The site markets itself as a way to understand risks "without needing a lawyer." While AI is excellent for spotting standard risky clauses (like extreme liability indemnifications or sneaky auto-renewals), users should be cautious about relying solely on AI for high-stakes, nuanced agreements. A disclaimer emphasizing that VIDI is an educational/preventative tool rather than a complete replacement for legal counsel on massive deals would add an extra layer of professional credibility. I'll admit VIDI is a sleek, hyper-focused, and incredibly useful web application. Its minimalist design perfectly contrasts the complexity of the problem it is trying to solve. By offering an accessible, automated way to vet contracts and providing plain-English explanations of legal pitfalls, VIDI stands out as a highly valuable digital asset for freelancers, startup founders, and small business owners.
Appreciate the thoughtful critique - that’s a very fair point.
The goal with VIDI isn’t to replace lawyers, especially for high-stakes or complex agreements. It’s more about helping founders and small business owners quickly spot potential risks and understand what they’re signing in plain language before moving forward.
In many cases it’s meant to act as a first layer of review - highlighting areas that might deserve a closer look or professional advice.
Glad the design and approach resonated, and thanks for the detailed feedback.
The reframe from "contract analysis" to "am I about to sign something that could cost me money?" is the key insight here. That's the actual job-to-be-done. One thing I'd add from building in the legal/HR space: the contract is only half the story. When disputes arise, the email thread leading up to signing often matters just as much as the document itself. "We agreed that X would be included" becomes critical evidence, and if it's buried in a 200-message chain, good luck reconstructing it. A workflow that helps founders understand contract risk at signing, combined with clean documentation of what was discussed beforehand, is where the real protection lives. Curious whether VIDI users are thinking about the pre-signature communication trail at all, or purely focused on the document itself.
That’s a really good point. The document is only part of the story - the context around it often matters just as much.
Right now most people using VIDI are focused on the contract itself and the clauses they’re about to sign, but the communication trail before signing is definitely an interesting layer. A lot of real disputes seem to come from “we thought this was included” vs what the contract actually says.
Capturing that expectation gap is a really interesting direction to think about.
The trust insight resonates hard. Working in court recording tech, I've seen how vendor lock-in clauses in equipment contracts can quietly bankrupt small court systems. One county signed a recorder maintenance contract with a 5-year auto-renewal buried in section 12.4 — didn't notice until year 3 when they wanted to upgrade.
Your reframing from "contract analysis" to "will this cost me money later" is brilliant. That's exactly how stressed founders think at 11pm before a deadline.
One pattern I've noticed: the riskiest clauses are often the shortest. "Vendor may adjust fees annually at their discretion" sounds reasonable until you realize there's no cap. A tool that flags those sneaky 8-word gotchas would be gold.
That’s a great example of the exact pattern I keep seeing - the most expensive problems often come from the smallest clauses.
Things like auto-renewals, uncapped fee adjustments, or vague termination terms look harmless when you skim the contract, but they can create huge problems later.
The goal with VIDI is exactly what you described: flag those short “gotcha” clauses and explain in plain language what they could actually mean for the business before someone signs.
Appreciate you sharing that real-world case - it’s a perfect example of the kind of risk many founders don’t notice until it’s too late.
The reframing insight is gold — "am I about to sign something that could cost me money?" vs "contract analysis." That's exactly the kind of language shift that makes or breaks an AI tool's adoption.
I'm building an AI email tool (Drafted) and had the exact same realization. Nobody searches for "AI email composition assistant." They think: "I have 47 emails I haven't replied to and I don't know where to start." The tool that meets people in their actual problem framing wins.
Your point about trust is spot on too. For anything touching sensitive data — contracts, emails, financial docs — users need to trust the founder AND understand exactly what happens to their data. That's why we went fully local (everything processes on the user's machine, nothing goes to the cloud) and made it so the AI never sends anything without human approval. The trust bar for AI touching your business communications is sky-high.
Curious: as you iterate on VIDI, are you finding that users want more explanation of WHY a clause is risky, or is the simple flag enough? Wondering if the same pattern applies across AI tools — do people want the reasoning, or just the verdict?
Great point about problem framing.
What I’m seeing so far is that the “flag” alone usually isn’t enough. People want to understand the reasoning - but not in heavy legal language.
The most useful pattern seems to be:
risk → plain explanation → what it could mean for the business.
For example, instead of just saying a clause is risky, explaining what could actually happen in practice if that clause is triggered.
Still early, but that kind of context seems to help founders trust the analysis much more.
Really appreciate the mention!
One thing I’ve noticed with AI tools is that trust usually comes from showing the reasoning, not just the result. When users can see the exact clause that triggered the warning, it turns the tool from a “mystery box” into something they can actually learn from.
Excited to see where you take VIDI next. Tools that help founders understand contracts before signing are badly needed.
Thanks, I appreciate that.
One thing that surprised me while building this is how much product direction can come from conversations with founders. A single comment sometimes reveals a problem you hadn't thought about before.
Good luck with your lineup optimizer as well - building in public and getting feedback early can be really powerful.
Yeah, that’s one of the underrated benefits of building in public. Sometimes a single comment surfaces a problem or use case you wouldn’t have discovered on your own.
It’s almost like free product research if you’re paying attention to the patterns in what people ask or react to.
Appreciate the encouragement on the lineup optimizer too — still early, but I’m hoping the same feedback loop helps shape it into something useful.
Exactly - sometimes a single comment reveals a use case you wouldn’t have thought about otherwise.
That feedback loop is one of the best parts of building in public.
That’s a great point. Sometimes a single comment ends up revealing how someone actually thinks about the problem, which can be very different from the way the builder originally framed it.
It almost turns the comment section into a kind of informal user research. People describe real situations they’ve run into, and suddenly you see edge cases or use cases that wouldn’t come up in a normal product brainstorming session.
Have you had any moments yet where a comment or piece of feedback made you rethink a feature or adjust the direction of the tool?
Yes - actually one of the biggest shifts came from the way founders talked about the problem.
Originally I framed the product more around “contract analysis.” But after reading comments and talking to founders, it became clear that most people don’t think in those terms. They’re usually asking a much simpler question: “Is there anything here that could cost me money later?”
That insight changed how I started presenting the analysis. Instead of focusing only on legal explanations, I began structuring the output around the potential real-world impact of the clause.
So in a way the discussions themselves helped shape the product positioning. The feedback loop made it much clearer how founders actually think about contracts in practice.
That’s a really interesting shift. The way founders frame the problem often ends up shaping the product more than the original idea itself.
“Contract analysis” sounds like a legal task, while “is this going to cost me money later?” feels like a practical decision founders need to make quickly. Changing that framing probably makes the tool much easier to understand immediately.
It’s also interesting that the positioning came directly from conversations. Building in public seems to create that feedback loop where the market almost helps refine the messaging.
Curious if you’ve found that founders want the analysis primarily before signing, or are some using it more as a way to review contracts they’ve already agreed to?
From what I’ve seen so far, most people are interested in using it before signing. That’s when the question “is there anything here that could cost me money later?” feels the most urgent.
But interestingly, some founders also upload contracts they’ve already signed just to understand them better. In a few cases people told me they wanted to see if there was anything they should pay attention to for the next renewal or negotiation.
So it’s starting to look like two use cases: a quick risk check before signing, and a way to understand what you’ve already agreed to after the fact.
That’s interesting — the “before signing” use case makes sense, but the after signing one is actually pretty powerful too.
Once something is already signed, people usually stop thinking about it until renewal or a problem shows up. Having a way to revisit the agreement and understand what might matter later could make negotiations a lot easier the next time around.
That’s a good observation.
Once something is signed, people often shift their attention to running the business and only revisit the agreement if something triggers it - a renewal, a dispute, or a change in the relationship.
In that sense, going back to the contract later can sometimes reveal details that didn’t seem important at the time but become more relevant once real situations start unfolding.
This is a valuable topic for founders. Clear contracts can prevent many problems later when the business starts growing.
Absolutely. A lot of founders I spoke with said the same thing - contracts often feel like a formality when you're just starting out, but small clauses can become big problems once the business grows.
That's actually what pushed me to start building VIDI. Many issues only appear months later when someone rereads the agreement.
This is a great breakdown. As a solo dev building a document collection tool, I'm constantly thinking about the 'legal friction' of getting clients to sign or upload sensitive docs. In your research, did you find that shorter, simpler contracts actually improved the speed of document turnaround, or does the extra detail provide necessary peace of mind for the client?
Great question.
From what I've seen talking to founders, shorter contracts usually do help with speed. When agreements are simple and easy to scan, people are more comfortable signing quickly.
But interestingly, the issue isn't always the total length. Many founders told me the real friction comes from not understanding a few specific clauses - things like liability, termination, or auto-renewal.
So the goal with VIDI isn't necessarily to shorten contracts, but to surface the risky parts and explain them in plain English. When founders understand what those clauses actually mean in practice, they feel much more comfortable moving forward.
Curious what you've seen on your side while building the document collection tool.
The reframing from "contract analysis" to "am I about to sign something that could cost me money later" is a masterclass in positioning. The first is a feature description, the second is the actual fear the user has. That one insight alone is worth 300 comments.
The trust point about showing exactly where the AI found the risky clause is critical for legal adjacent tools — black box answers don't work when the stakes are real money and real liability.
Building klovio .co which sits at the other end of the same problem — protecting freelancers after delivery when payment goes wrong. The contract protects you at signing, we protect you at handover. Would love to connect and swap notes on what we're each learning from freelancers.
That's a really interesting way to put it.
You're right - the shift from "contract analysis" to the actual fear a founder has before signing was a big insight for me. Most people don't wake up thinking they need legal analysis; they just don't want to accidentally sign something that creates problems later.
The trust point is also something I'm thinking a lot about. For legal tools, showing where the clause is and explaining why it matters seems much more important than just giving a black-box risk score.
Klovio sounds interesting as well - it's almost the other side of the same lifecycle problem. I'd definitely be curious to compare notes on what you're seeing from freelancers.
Exactly — other side of the same lifecycle is the perfect way to describe it. Contract protects you at signing, Klovio protects you at handover. Two different anxiety points for the same freelancer.
Appreciate the perspective - the “two anxiety points” framing is a great way to put it.
Your work with freelancers sounds like an interesting angle on the same problem space. I’m currently pretty focused on building and iterating on VIDI, but feel free to reach out on LinkedIn and we can definitely exchange ideas when there’s a good moment.
Always happy to hear what others are seeing from real users as well.
Great will definitly reach you out on linkdin
Sounds good - feel free to reach out anytime.
Always interesting to compare notes with people working on adjacent problems. Looking forward to hearing what you're seeing from freelancers as well.
This was super insightful. Most small businesses (including mine) tend to treat contracts as a formality, not a real source of risk, until something goes wrong. Hearing what 300+ founders actually struggled with makes the hidden risks much more concrete, and it also makes tools like VIDI feel genuinely useful instead of just “nice to have.”
Thanks, I really appreciate that perspective.
That’s something I’ve been hearing quite a lot while talking with founders. Many people treat contracts as a formality until something goes wrong later.
The interesting part is that the real concern often appears right before signing, when someone suddenly wonders if there’s a hidden clause or risk in the agreement.
Curious - what kind of contracts do you usually deal with in your business?
This is a really good problem to work on. I’ve seen many founders sign contracts quickly just to move things forward, and only later realize there was something risky inside.
I like the idea of showing exactly where the risky clause is instead of giving a black-box answer. That builds trust.
One small thing I’ve learned: founders usually want a very quick summary first, then the details if needed. A simple “top 3 risks” view could help a lot.
Thanks for the thoughtful feedback.
The “quick summary first” idea is something I’m hearing from several founders as well. Many people seem to want a fast overview of the biggest risks before diving into the full analysis.
Something like a “top 3 risks” section with links to the exact clauses could make the results much easier to scan.
Still experimenting with the output format, but insights like this are really helpful while shaping the product.
Will you make a subscription with premium features like big size files or deep ai research?
That's something I'm planning for the future.
Right now the tool is free while I'm testing it and learning from early users. Later it will likely move to a subscription model with additional features in higher tiers.
That insight about founders not thinking in terms of “contract analysis” but instead “could this cost me money later?” is really spot on.
I’ve noticed something similar while exploring tools for WorkflowAces — how you frame the problem often matters more than the technical capability itself. When the language matches how people actually think, the product suddenly makes much more sense.
That's a great observation.
I've started noticing the same thing while talking to founders - most of them don't think about "contract analysis" as a category. The real trigger moment is when they're about to sign something and wonder if there's a hidden risk.
Framing the problem around that moment seems to resonate much more than describing the technical capability of the tool.
Appreciate you sharing that example.
Yeah exactly, that “moment before signing” is really the key trigger. Most founders don’t go looking for contract analysis tools, they just want quick clarity before committing to something.
Feels like framing the product around that moment could make it much easier for people to immediately understand the value.
Exactly - that “moment before signing” seems to be the real trigger.
In several conversations with founders, many said they usually skim contracts quickly and only start worrying right before signing.
That’s the moment where a quick risk summary becomes much more valuable than a full legal analysis.
Still learning from how people actually review agreements, but those patterns are starting to appear pretty clearly.
That makes a lot of sense. The timing really changes how people perceive the value. A quick risk summary right before signing is exactly what most founders probably need.
Yeah, exactly. Timing seems to matter a lot.
When someone is actively about to sign an agreement, even a quick summary of potential risks can be incredibly valuable compared to a full legal-style analysis.
That moment of uncertainty right before committing seems to be where tools like this can actually help the most.
Huge thanks again to everyone who shared thoughtful feedback in the earlier discussions.
Many of the ideas mentioned there already influenced how I'm improving the product and how I'm thinking about positioning.
One thing I'm still trying to understand better:
How do you usually review contracts before signing in your business?
Do you typically:
Curious how founders here actually deal with contracts in real life.