I built an AI contract analysis tool for SMBs - looking for feedback

This is a fantastic tool!

It would be incredibly helpful if, after generating the TOC, there was an option to export the document as a .docx file for further editing.

Even if that feature is missing for now, it's not a dealbreaker. I’ve been using ConvertOnline to handle my PDF, and it’s been a lifesaver for quickly re-processing files.

Interesting idea. Contract review is definitely an area where AI can add a lot of value, especially for small businesses that don’t have access to legal teams.

One feature I’d personally find useful is having the tool highlight not just risks, but also explain them in plain language with examples — something like “this clause could allow the other party to terminate early” along with a quick explanation of what that means in practice.

Another thing that could be interesting is a risk score or summary that helps founders quickly understand whether a contract is relatively safe or if it needs professional review.

Curious — are you focusing mostly on specific types of contracts (like SaaS agreements, vendor contracts, NDAs, etc.), or is the model meant to handle any document type?

Good timing on this — contract review and invoice follow-up are two sides of the same SMB problem. One is protecting revenue before work starts (contracts), the other is recovering it after (chasing payment when clients don't pay).

The follow-up side is often more painful: you get a contract signed, do the work, and then spend weeks chasing the invoice. Most small founders don't have a system for it, so they just... accept the loss rather than send that third awkward email.

Question for you: does VIDI flag payment terms within contracts? That's often where the real risk is — net-60 clauses, vague 'payment due upon completion' language, missing late fee provisions. Small founders rarely negotiate these and it costs them.

(We built the invoice chase side at tryrecoverkit.com — free follow-up templates for freelancers + automated Stripe payment recovery for SaaS)

Congrats on the launch, Meirambek!

The biggest gap I see in AI contract tools right now is focusing only on 'legal language' while ignoring Operational Intent.

At AlfaNest Labs, we deal with high-stakes Web3 security, and what we’ve learned is that a contract can be legally perfect but operationally a disaster—something we call 'Semantic Drift'.
Does VIDI analyze the logical flow of functions, or just the text? For example, if a clause allows for a hidden 'kill switch' or liquidity withdrawal, is your AI trained to flag that as a critical risk, or just a standard term?
I’m building Clearance (CL) to provide actual Verdicts (Granted/Denied) based on 25 operational functions, not just highlights.
Curious to see how you plan to bridge the gap between 'scanning' and 'decision making'.

Really solid problem to tackle! As a fellow AI founder, I've found that legal friction is one of the biggest blockers for small businesses.

We found similar pain points when building Kintsu.ai, our WordPress AI platform - businesses often avoid using new tools because of complex legal processes. Your approach of making contract risks clear in plain language is spot on.

Curious - have you considered focusing on WordPress service providers? They deal with contracts constantly (hosting agreements, development contracts, etc.) and tend to be very tech-forward early adopters.

Nice problem to tackle… a lot of SMBs definitely sign stuff without fully understanding the risks.

Getting 1k organic visitors this early is solid too. Curious to see how the AI explanations evolve as more founders test it.

Great idea. If it saves time on reviewing contracts, it could be very valuable for small businesses.

Interesting idea. SMBs usually struggle with legal costs.

Are you focusing on contract review, risk detection, or full contract summaries?

Curious what the main use case is for early users.

Great work on the AI tool! I'm also building an AI project (Lumen AI) from Congo. How did you get your first users?

One thing that helped me in a project I'm building was letting users try the product before signup. Good Job

I wish I had come across this article in the past few months. This is an incredibly clever business idea, congratulations. Investment agreements or contracts in sectors like construction can sometimes even lead to companies going bankrupt.

Interesting approach. I'm curious how you validated the need for this before building it. Did you talk to potential users first or build it based on a problem you personally experienced?

Nice progress

Interesting project.

How did you validate the demand before building the MVP?

Did you talk with SMB owners first or test the idea with a landing page?

Hey, this looks interesting.

I think the problem is real. Many small businesses sign contracts but they don’t fully understand the legal language.
One thing I’m curious about: do users only want to see the risk, or do they want help to change the contract?
For example, it could be very useful if the tool also suggested: a safer version of a clause what to ask during negotiation
Another thought: maybe focusing on one type of user could help. For example freelancers, SaaS founders, or small agencies. They often deal with similar contracts again and again.
Just my thoughts. Curious to see how people are using VIDI so far.

Good luck with the project!

I took a look at it, and it seems very useful. I can well imagine that it could have a lot of potential in the future. I also believe that approaching companies directly is the right approach. It's a cool project, and I wish you every success.

I really like the design — it’s simple, clean, and elegant. The interface looks great and feels well thought out. The idea itself is strong as well. Helping small businesses is something every SMB owner can benefit from. I’ll definitely keep this in mind the next time I have something I need to review, and if I come across a small business that could benefit from it, I’ll be sure to pass them your way.

This sounds so useful. How are you getting the word out currently? Have you been running any paid marketing?

This is a great idea! Contract analysis is definitely a high-friction area for SMBs. I've found that keeping the UI simple and the analysis results very actionable is key for this target market. Have you considered offering a "summary" mode for quick checks? Best of luck with VIDI!

Law firms are a strong ICP for this. Contract review is one of the highest-friction tasks for small firm attorneys, especially when they are not specialists in the contract type in front of them. Two questions: (1) Are you targeting the review/markup workflow or the extraction/analysis side? (2) Have you talked to any solo practitioners yet? The workflow at a 3-person firm vs. a 20-person firm is quite different in terms of how contracts flow and who touches them.

This is a great problem to tackle. As a fellow solo founder building AI tools, I know firsthand how painful contract review can be for small businesses. The risk-highlighting approach sounds really practical. Curious - are you targeting specific industries or keeping it broad? Would love to hear how early users are responding.

Fellow AI builder here — I’m running 6 AI apps right now, and I know the solo founder grind well. Contract analysis is a sharp niche because the pain is real and the willingness to pay is there. One question: are you targeting a specific vertical (e.g., SaaS vendors, agencies) or going broad SMB? In my experience, picking one beachhead market early makes your messaging and distribution way easier.

Cool idea, Meirambek. The SMB contract space is really underserved — most small business owners I've talked to either skip reading contracts entirely or pay a lawyer $300/hr for something that should take 10 minutes.

A couple of thoughts from a fellow solo founder (I'm building Testimon, a testimonial collection tool):

1. The "speaking with small business founders" part is huge. That's where the real product insights come from. When I started doing this for my own product, it completely changed my roadmap.

2. For getting more businesses to test: have you tried reaching out in niche communities where SMBs hang out? Facebook groups for freelancers, Slack communities for agency owners, etc. Those channels converted way better for me than broad marketing.

3. One feature idea: a "plain English summary" toggle that rewrites each flagged clause in simple language. That would be a massive differentiator vs. just highlighting risks.

1,000 organic visitors at MVP stage is impressive. What's your main acquisition channel so far?

you have a good potential

很有帮助

Contract analysis is high-stakes! How do you ensure the AI doesn't miss critical risk clauses?

"Thanks for the breakdown! Risk detection is a huge pain point for SMBs. I’m actually working on the 'pre-contract' side of things with ClientRadar—helping freelancers find projects and generate AI proposals. I can see a world where someone uses my tool to win the bid and yours to make sure the contract is safe. Great to see more AI tools focusing on protecting and helping solo founders!"

The ICP clarity makes this or breaks it. "SMBs" is too wide. A marketing agency reviewing freelancer contracts is solving a completely different problem than a SaaS startup reviewing vendor agreements. The risk they care about, the clauses they flag, the language they understand, all different.

What specific contract scenario are you solving best right now? Because that's probably your real ICP and everything else is noise.

SMB contract analysis is a genuinely interesting space because the problem is real but the buyer is hard to reach.

Enterprise has legal teams and existing procurement for this. Consumer has free tools or just ignores it. SMBs are the ones who actually read contracts themselves, know they are missing things, and feel the risk acutely but do not have budget for a lawyer on retainer.

The feedback I would offer: the risk of AI tools in legal-adjacent spaces is the confidence calibration problem. If the tool says a contract looks clean and it misses something, the buyer is worse off than if they had reviewed it carefully themselves - because they now have a false sense of security. The product either needs to be very transparent about what it is and is not catching, or it needs to be positioned more narrowly as a starting-point review rather than a complete check.

The positioning that tends to work in this space: not we check your contract but we flag the things that most SMB founders miss and help you know what questions to ask a lawyer before you sign. That reframes it from replacement for legal review to preparation for it. Lower liability, more accurate for the actual use case, easier sell.

What is the specific type of contract you are targeting first? The problems in service agreements are very different from the problems in vendor contracts or partnership agreements.

This is exactly the kind of focused, single-purpose tool I love. Did you consider monetizing from day one or keeping it free to grow first?

This is exactly the kind of focused, single-purpose tool I love. Did you consider monetizing from day one or keeping it free to grow first?

The first $1K MRR is harder than $1K to $10K because you're still finding who actually buys.

Once you have 20-30 customers you can look at patterns — same job title, same company size, same trigger that made them buy now. That pattern is worth more than any marketing playbook because it tells you exactly who to go find next.

What was the common thread across your early customers?

Building in public has a timing problem people don't talk about enough.

Sharing early creates accountability and sometimes attracts early users. But premature sharing can also lock you into ideas before you've had a chance to discover what actually needs to be built. The sequence matters.

What I've seen work: share the problem and constraints publicly, share solutions privately with early users until there's signal, then share results publicly. Keeps the exploration honest without performing conviction you don't have yet.

Building in public has a timing problem people don't talk about enough.

Sharing early creates accountability and sometimes attracts early users. But premature sharing can also lock you into ideas before you've had a chance to discover what actually needs to be built. The sequence matters.

What I've seen work: share the problem and constraints publicly, share solutions privately with early users until there's signal, then share results publicly. Keeps the exploration honest without performing conviction you don't have yet.

Building in public has a timing problem people don't talk about enough.

Sharing early creates accountability and sometimes attracts early users. But premature sharing can also lock you into ideas before you've had a chance to discover what actually needs to be built. The sequence matters.

What I've seen work: share the problem and constraints publicly, share solutions privately with early users until there's signal, then share results publicly. Keeps the exploration honest without performing conviction you don't have yet.

Building in public has a timing problem people don't talk about enough.

Sharing early creates accountability and sometimes attracts early users. But premature sharing can also lock you into ideas before you've had a chance to discover what actually needs to be built. The sequence matters.

What I've seen work: share the problem and constraints publicly, share solutions privately with early users until there's signal, then share results publicly. Keeps the exploration honest without performing conviction you don't have yet.

Feedback collection is easy. Acting on the right feedback is the hard part.

The mistake I see a lot: collecting feedback broadly, then building for the most vocal people. Vocal people in your feedback channels are not always your target customers. Sometimes they're power users who want features that would confuse everyone else.

Better filter: whose feedback would actually change your revenue or retention if you acted on it? Build for those people. Ignore the rest, politely.

Cold outreach works better for founders than it does for SDRs and people underestimate why.

SDRs are optimizing for pipeline. Founders are optimizing for information. A "no" from a founder is still a data point about positioning, audience fit, or messaging. An SDR gets nothing from a no.

This changes how you write the email. If your goal is learning, you're less desperate, and the email reads differently. The best cold emails from founders feel like genuine curiosity about whether there's a fit - because there is genuine curiosity.

Building in public has a timing problem people don't talk about enough.

Sharing early creates accountability and sometimes attracts early users. But premature sharing can also lock you into ideas before you've had a chance to discover what actually needs to be built. The sequence matters.

What I've seen work: share the problem and constraints publicly, share solutions privately with early users until there's signal, then share results publicly. Keeps the exploration honest without performing conviction you don't have yet.

Building in public has a timing problem people don't talk about enough.

Sharing early creates accountability and sometimes attracts early users. But premature sharing can also lock you into ideas before you've had a chance to discover what actually needs to be built. The sequence matters.

What I've seen work: share the problem and constraints publicly, share solutions privately with early users until there's signal, then share results publicly. Keeps the exploration honest without performing conviction you don't have yet.

Feedback collection is easy. Acting on the right feedback is the hard part.

The mistake I see a lot: collecting feedback broadly, then building for the most vocal people. Vocal people in your feedback channels are not always your target customers. Sometimes they're power users who want features that would confuse everyone else.

Better filter: whose feedback would actually change your revenue or retention if you acted on it? Build for those people. Ignore the rest, politely.

Building in public has a timing problem people don't talk about enough.

Sharing early creates accountability and sometimes attracts early users. But premature sharing can also lock you into ideas before you've had a chance to discover what actually needs to be built. The sequence matters.

What I've seen work: share the problem and constraints publicly, share solutions privately with early users until there's signal, then share results publicly. Keeps the exploration honest without performing conviction you don't have yet.

Feedback collection is easy. Acting on the right feedback is the hard part.

The mistake I see a lot: collecting feedback broadly, then building for the most vocal people. Vocal people in your feedback channels are not always your target customers. Sometimes they're power users who want features that would confuse everyone else.

Better filter: whose feedback would actually change your revenue or retention if you acted on it? Build for those people. Ignore the rest, politely.

Cold outreach works better for founders than it does for SDRs and people underestimate why.

SDRs are optimizing for pipeline. Founders are optimizing for information. A "no" from a founder is still a data point about positioning, audience fit, or messaging. An SDR gets nothing from a no.

This changes how you write the email. If your goal is learning, you're less desperate, and the email reads differently. The best cold emails from founders feel like genuine curiosity about whether there's a fit - because there is genuine curiosity.

Building in public has a timing problem people don't talk about enough.

Sharing early creates accountability and sometimes attracts early users. But premature sharing can also lock you into ideas before you've had a chance to discover what actually needs to be built. The sequence matters.

What I've seen work: share the problem and constraints publicly, share solutions privately with early users until there's signal, then share results publicly. Keeps the exploration honest without performing conviction you don't have yet.

Cold outreach works better for founders than it does for SDRs and people underestimate why.

SDRs are optimizing for pipeline. Founders are optimizing for information. A "no" from a founder is still a data point about positioning, audience fit, or messaging. An SDR gets nothing from a no.

This changes how you write the email. If your goal is learning, you're less desperate, and the email reads differently. The best cold emails from founders feel like genuine curiosity about whether there's a fit - because there is genuine curiosity.

Cold outreach works better for founders than it does for SDRs and people underestimate why.

SDRs are optimizing for pipeline. Founders are optimizing for information. A "no" from a founder is still a data point about positioning, audience fit, or messaging. An SDR gets nothing from a no.

This changes how you write the email. If your goal is learning, you're less desperate, and the email reads differently. The best cold emails from founders feel like genuine curiosity about whether there's a fit - because there is genuine curiosity.

Building in public has a timing problem people don't talk about enough.

Sharing early creates accountability and sometimes attracts early users. But premature sharing can also lock you into ideas before you've had a chance to discover what actually needs to be built. The sequence matters.

What I've seen work: share the problem and constraints publicly, share solutions privately with early users until there's signal, then share results publicly. Keeps the exploration honest without performing conviction you don't have yet.

Feedback collection is easy. Acting on the right feedback is the hard part.

The mistake I see a lot: collecting feedback broadly, then building for the most vocal people. Vocal people in your feedback channels are not always your target customers. Sometimes they're power users who want features that would confuse everyone else.

Better filter: whose feedback would actually change your revenue or retention if you acted on it? Build for those people. Ignore the rest, politely.

Interesting problem to solve. The SMB legal market is underserved by AI tools that are built for enterprise.

One question on positioning: are you targeting the business owner who has no legal background, or the small firm attorney who has too many contracts to review manually? The pain is similar but the purchase decision is different - one buys on "I can finally understand this" and the other on "I can process more without hiring".

What does your current user base look like?

Feedback collection is easy. Acting on the right feedback is the hard part.

The mistake I see a lot: collecting feedback broadly, then building for the most vocal people. Vocal people in your feedback channels are not always your target customers. Sometimes they're power users who want features that would confuse everyone else.

Better filter: whose feedback would actually change your revenue or retention if you acted on it? Build for those people. Ignore the rest, politely.

Feedback collection is easy. Acting on the right feedback is the hard part.

The mistake I see a lot: collecting feedback broadly, then building for the most vocal people. Vocal people in your feedback channels are not always your target customers. Sometimes they're power users who want features that would confuse everyone else.

Better filter: whose feedback would actually change your revenue or retention if you acted on it? Build for those people. Ignore the rest, politely.

Feedback collection is easy. Acting on the right feedback is the hard part.

The mistake I see a lot: collecting feedback broadly, then building for the most vocal people. Vocal people in your feedback channels are not always your target customers. Sometimes they're power users who want features that would confuse everyone else.

Better filter: whose feedback would actually change your revenue or retention if you acted on it? Build for those people. Ignore the rest, politely.

Feedback collection is easy. Acting on the right feedback is the hard part.

The mistake I see a lot: collecting feedback broadly, then building for the most vocal people. Vocal people in your feedback channels are not always your target customers. Sometimes they're power users who want features that would confuse everyone else.

Better filter: whose feedback would actually change your revenue or retention if you acted on it? Build for those people. Ignore the rest, politely.

Building in public has a timing problem people don't talk about enough.

Sharing early creates accountability and sometimes attracts early users. But premature sharing can also lock you into ideas before you've had a chance to discover what actually needs to be built. The sequence matters.

What I've seen work: share the problem and constraints publicly, share solutions privately with early users until there's signal, then share results publicly. Keeps the exploration honest without performing conviction you don't have yet.

The framing here is useful. The research layer before any outreach is what most people skip because it does not scale well manually. But it is where the ROI actually lives - a tight ICP plus context on each target outperforms volume every time.

This is a really interesting use case for AI.

Highlighting risks is great, but I think many SMB founders would also benefit from simple summaries of each clause in plain language so they can quickly understand what they’re agreeing to.

I've just launched something similar(ish) but focused on tech project statements of work: sowscannerDOTcom

I dropped using only AI because I was only getting scoring flattened to the middle, rather than a proper analysis and scoring, so I implemented a hybrid AI+algo engine.

I like the effort you've put into it!

The use case makes sense - SMBs genuinely do not have legal review bandwidth and this kind of risk flagging is useful.

A few questions that would sharpen the product direction:

What is the current workflow you are replacing? Is it 'upload to ChatGPT and ask questions' or 'pay a lawyer 00 to review' or 'sign without reading?' The answer changes your positioning and your price point significantly.

The hardest part of selling to SMBs is that they often do not know they have a contract problem until they have a contract problem. What triggers make someone search for this? A bad experience, a new vendor relationship, advice from an accountant?

On the AI trust angle: SMB owners often distrust AI for anything 'legal.' Framing as 'flags clauses worth asking your lawyer about' rather than 'reviews your contract' tends to land better - it positions you as the research layer rather than the advice layer.

What is your acquisition channel so far? The feedback quality here will help focus the roadmap.

Cold outreach has a reputation problem because 95% of it is terrible. The 5% that works is almost always the same pattern: the sender clearly did homework, found something specific to reference, and made the ask extremely low-friction.

The research step is the hard part. Most people skip it because it doesn't scale. But 50 well-researched emails at 10% reply rate beats 5000 blasted emails at 0.1% every time - and you learn faster from the replies.

What's your current research process before sending a cold email?

Smart angle on the contract analysis layer, Anders — clarity on risk before the work starts prevents a lot of payment issues after. The flip side: even with perfect contracts, SaaS founders still lose 5-9% MRR to failed payments (expired cards, soft declines). RecoverKit auto-fires a Day1/3/7 recovery sequence the moment Stripe flags an invoice failure. Beta is free — would love your take: tryrecoverkit.com/connect

Interesting problem to solve. The SMB legal market is underserved by AI tools that are built for enterprise.

One question on positioning: are you targeting the business owner who has no legal background, or the small firm attorney who has too many contracts to review manually? The pain is similar but the purchase decision is different - one buys on "I can finally understand this" and the other on "I can process more without hiring".

What does your current user base look like?

This is really cool i'm 17 years old from India building an AI toll for founders myself and the smb spaces genuinely under served by most enterprise workers software when you were validating this idea how did you figure out who your direct competitors were and how to position against them I am building compete iq which helps founders answer exactly the question and I am curious how other builders approach the competitive position before launching would love to hear your experience??

Contract review is such an underserved space for SMBs. lawyers are super expensive, not everyone can afford

Really cool idea! Contract risk for SMBs is such an underserved problem — most small business owners just skim through agreements and hope for the best.
1,000 organic visitors without paid marketing is impressive for an MVP. What's your current conversion rate from visitor to actually trying the product?
One suggestion — consider adding a "sample analysis" on the landing page so visitors can see exactly what they get before signing up. Seeing the output builds trust faster than any feature list.
What's been the most surprising feedback from the small business founders you've spoken to so far?

Really appreciate all the feedback in this thread.

A few people from here actually tried the tool and uploaded real contracts, which has been incredibly helpful for improving the product.

I also shared a short follow-up post about what happened after this discussion and what I learned from the feedback here:
https://www.indiehackers.com/post/what-happened-after-my-ai-contract-tool-post-got-70-comments-e89c3756b5

If anyone else wants to test the tool with their own agreements, I’d love to hear your feedback as well.

Quick update for everyone following this thread.

I wrote a follow-up post sharing what happened after this discussion and some of the feedback I received here while building the product.

If anyone is curious, you can read it here:
https://www.indiehackers.com/post/what-happened-after-my-ai-contract-tool-post-got-70-comments-e89c3756b5

Interesting project. I like the idea of focusing on SMBs, a lot of people sign contracts without really understanding them.

I also think there’s something valuable in having a tool that’s very simple and built specifically for this use case. Technically anyone could paste a contract into one of the big AI tools, but it’s not always very intuitive, and the privacy side of that can be a bit unclear.

Two things I’d be curious about:

First, how do you see this interacting with lawyers if the product grows? I could imagine some pushback, but also cases where it becomes a useful first pass before legal review.

Second, how are you handling privacy and data on the backend? Contracts can contain very sensitive information, so things like data retention or third-party APIs seem pretty important.

Curious how you’re thinking about those.

Hi Meirambek,
VIDI looks really promising! If you want, I can share a quick idea to bring more SMBs testing the tool and giving actionable feedback this month. Would love to help.

Interesting idea.
Do you focus mostly on highlighting risky clauses or also explaining the contract in simpler language?

so then your RAG has to have all legal base in order to answer thoroughly? Or do you engage some shortcuts?

Idea is great, I know a guy who sold legal consulting based on AI for 700M when ChatGPT 4 was introduced.

feels like a "paste contract into claude code or codex" lightweight frontend....

Something I have noticed talking to small law firms and legal ops teams: the contract signing moment is actually the easy part. The hard part is when something goes sideways 6 months later and both sides have a different interpretation of what was agreed — at that point, the contract AND the email thread leading up to signing become the evidence. That context pushed me to think about output formats: a timestamped summary of what was agreed to and when has real legal weight beyond just a risk report. Could be a compelling differentiator if VIDI generated a shareable artifact users could actually produce in small claims or mediation — not just a risk flag they read once before signing.

This is a promising idea. I’ve watched SMBs either ignore contract risk or pay a lawyer for things they mainly need clarity on.
If I were evaluating this, I’d want to see :

1. a few concrete outputs like “top 5 risky clauses + suggested edits,”
2. strong privacy/security messaging (upload handling, retention, SOC2 roadmap, etc.),
3. a clear boundary that it’s not legal advice but a decision-support tool.

If you can make the workflow “upload → redlines → summary for my lawyer/partner,” I can see this being very sticky.

The net-30/60 gap is underappreciated. A lot of SMB founders accept those terms without realizing they've just agreed to be a 30-60 day bank for a larger company. The missing late fee provision is even sneakier — without it, there's no contractual incentive for the client to pay on time.

The framing I'd suggest for that analysis: 'cash flow risk score' on payment terms. A contract with net-60, no late fees, and an evergreen renewal clause is a fundamentally different cash flow risk than net-15 with 1.5%/month late fees. A single score that synthesizes those factors would make it immediately actionable for a founder who doesn't have time to read the legal analysis.

Glad the product is evolving toward payment terms — that's genuinely one of the areas where contract AI can prevent real financial pain rather than just legal exposure.

The use case is solid — SMBs signing contracts without legal review is a real and common problem, and the fear of missing a clause is visceral. That emotional hook should be front and center in your positioning.

A few things worth testing:

The "what's your biggest concern about contracts" question in your onboarding is smart. That data will tell you which risk categories actually drive fear for your users (payment terms, liability caps, IP assignment, auto-renewal traps). Build your feature roadmap around the top 3 answers.

On pricing: I'd be cautious about per-contract pricing for the SMB segment — the user who needs this most is also the one who'll hesitate on each contract because of cost. A flat monthly fee for "unlimited" tends to remove the friction at the moment of decision.

One honest challenge for tools in this space: getting users to trust the output. The first time the AI misses something important, they'll stop trusting it entirely. Consider how you'll communicate confidence levels on each flag.

What's the story of your first 10 users — how'd you find them?

Fellow solo founder building with AI here. A few thoughts from someone who works in digital marketing consulting and sees how SMBs actually operate:

The problem is real. Most small business owners sign contracts they don't fully understand because lawyers are expensive and slow. The friction of getting a contract reviewed often means they just skip it. If your tool can make that review feel as easy as running a spell check, you've got something.

One positioning thought: "AI contract analysis" describes what the tool does, not what the business owner gets. Consider framing it around the outcome -- something like "know exactly what you're signing before you sign it" or "catch the clause that costs you $10K." SMB owners don't think in terms of "contract analysis" -- they think in terms of "am I about to get screwed?"

1,000 organic visitors is solid traction for this stage. The fact that you're talking to actual SMB founders about how they currently handle contracts is the right move. That's where your real positioning and feature roadmap will come from -- not from assumptions.

Curious: what's the conversion path from those 1,000 visitors? Are they uploading contracts, or just browsing? That'll tell you a lot about whether the problem is awareness vs. trust.

My personal Opinion .. I like your concept about VIDI it's can help SMBs and SaaS platform to sign any contract.

I would like to suggest that , You need to improve your website UI and over all structure and because for legal languages you need to mostly focus on trust. To make trust Improve website and should need to buy a TLD domain.

Solid idea and impressive traction for an MVP — 1k organic visitors is a real signal.

One thing that could sharpen the analysis quality: the prompt you're using to instruct the AI on what to flag matters as much as the model itself. Contract risk extraction is very constraint-heavy — what counts as a risk depends on industry, jurisdiction, and company size. Structuring those parameters explicitly (rather than leaving them implicit in a single system prompt) tends to get much more consistent output.

Building in a similar space with flompt — a visual prompt builder that helps structure exactly that kind of complex instruction set. Might be useful for iterating on your analysis prompts. If you try it, a ⭐ on github.com/Nyrok/flompt would mean a lot — solo founder here too 🙏

Great idea! What's your main acquisition channel?

Really great concept, working in sales, lots of the SMB clients have issues with their contract process. In terms of launching and organic visitors, what were you using for marketing and pushing the product out there? I'm stuck trying to get the right eyes on right now.

Congrats on shipping the MVP!
This is a really interesting problem because many SMB founders sign contracts without fully understanding the legal language, so an AI tool that highlights risks and explains clauses in plain English could be very valuable.

I’m curious how are you handling accuracy and trust? For example, do you plan to add confidence scores or recommendations like “consult a lawyer” for higher-risk clauses?

Also, I work with automation and developer tools and would be interested in exploring a potential collaboration (integrations, workflow automation, etc.). Happy to test the product and share detailed feedback if helpful.

I respect your launching on a raw netlify.app. I'm terrible at launching early and usually have a custom domain launched and even routing email... way to much infra up front.

Hey there!

I like the idea that you're working on but I couldn't view the website and I got
"This site can’t be reached" error message. Maybe it's just because I'm using my university's internet but just wanted write it down so you can double check it if there's any general error in the website.

Good luck!

Really cool that you're tackling this as a solo founder. I've been on the receiving end of badly worded contractor agreements and honestly most of the time I just skim them and hope for the best. Not great.

One thing I'd think about — the netlify subdomain might hurt trust a bit when you're asking people to upload sensitive legal docs. Even a cheap custom domain would probably improve conversion there. Small thing but it matters for this kind of tool.

Also curious how you're handling data privacy on the backend. Are uploaded contracts stored or processed in real-time and discarded? That'd be the first thing I'd want to know before uploading anything.

Great problem to tackle. I'm building something similar focused on the French market and individual freelancers. One thing I found important: suggesting alternative clauses directly in the analysis, not just flagging risks. Users want to know what to do, not just what's wrong. Good luck with VIDI

I had a similar idea, but I'm currently working on a different project. It's a good idea, but I think it would be wise to develop a roadmap to prepare for competition with evolving AI. It looks highly scalable. Good luck!