I'm a lawyer who launched an AI contract tool on Product Hunt today — here's what building it as a non-technical founder actually felt like
I had a problem I could see with perfect clarity.
And absolutely no idea how to build the solution myself.
After 10 years work in legal field, I'd watched the same scene play out dozens of times. A small business owner sits across from me. They've already signed the contract. It's already gone wrong. And somewhere in the fine print is a clause that should have been caught weeks ago — before anyone signed anything.
Every time, I'd think: this is fixable. Someone should build a tool that makes this accessible before it becomes a crisis.
What I didn't realize was how hard it would be for that person to be me.
I'm not a software engineer. I can't read code — I spent years in law firm — but building a real AI product from the ground up? That's a different world. Every technical meeting felt like landing in a country where I spoke maybe 10% of the language. I could follow the general direction. I missed half the turns.
The hardest thing wasn't learning the technology.
It was learning to describe a legal problem in engineering terms — and learning to trust someone else to build the thing I could only see in my head.
I found my technical advisor Charles eventually. Eighteen years as a software engineer and now building in AI. We are a genuinely strange pair: I speak in clauses, obligations, and risk allocation. He speaks in models, pipelines, and inference costs. Somehow it works.
We launched EqualDocs on Product Hunt today.
It's an AI contract platform where both parties — not just one — can draft, review, negotiate, and sign, all in one place. The experience we built around: you shouldn't need a lawyer on call to know what you're agreeing to.
One thing I learned from early users that changed everything:
Nobody asks for "AI contract analysis." Nobody wakes up thinking about clause risk. What they actually feel is: I'm about to sign this. There's probably something I'm missing. I don't know what it is. I'll just hope it's fine.
That fear — not the legal complexity — is what we're really solving. When I stopped talking about features and started talking about that feeling, people got it immediately.
What EqualDocs does:
- AI-guided drafting from scratch or from your existing docs
- Risk flags in plain language — "this clause could cost you later," not "see Section 7.2(b)"
- Both parties on the same platform so negotiation isn't done over email chains
- Sign when you're both ready — no switching between five different tools
We're still early. Real beta users in Quebec. Backed by McGill Dobson Centre and HEC Montréal incubators. The numbers are honest, not inflated.
→ Try it free: equaldocs.com
→ Support us on Product Hunt today: producthunt.com/products/equaldocs
→ Link with me on linkedin: linkedin profile
One thing I'm still figuring out: how to stop thinking like a lawyer when I'm building a product. Lawyers are trained to close gaps, add caveats, cover every scenario. Founders have to ship before every scenario is covered. It's a muscle I'm still building.
My question for you:
Have you ever received a contract, told yourself you'd read it properly before signing — and then just… signed it anyway?
What was the thing you wish you'd caught?
I read every comment. Ask me anything about building in legaltech or being a non-technical founder in a technical space.
- Ningsi, Founder & CEO, EqualDocs
The "nobody asks for AI contract analysis, they feel scared before signing" reframe is spot on. Had the same realization building an iOS app — nobody searched for "cross-platform bookmark aggregator." They searched for "how to find saved TikTok videos" and "where did my Instagram saves go." The product description that worked was the one that matched the feeling, not the feature set. Your point about shipping before it feels ready is the hardest habit to build. As a technical founder I have the opposite problem — I keep wanting to add one more feature instead of putting it in front of real people. The non-technical constraint probably forced you to ship earlier, which is ironically an advantage.
This really resonates — the shift from talking about features to talking about the underlying feeling is one of those insights that sounds obvious in hindsight but changes everything. We're building an AI tool for ad creatives and had a very similar moment. We kept describing what the tool does (generates ads from a URL) but the real unlock was understanding that founders and small business owners feel overwhelmed by the gap between "I need to run ads" and actually having the design skills to make them. Nobody searches for "multi-platform ad creative generation" — they just know they're losing potential customers because they can't produce ads fast enough.
Curious about your experience as a non-technical founder working with AI specifically — how did you approach deciding what the AI should handle vs. what needed to stay human-driven? That balance between automation and trust feels especially critical in a domain like legal where the stakes of getting it wrong are high.
This really hits home — the feature‑to‑feeling shift is exactly what EqualDocs needed.
As a non‑technical founder, I leaned on the AI to handle the grunt work: finding risks, explaining them in plain language, and suggesting edits. What stayed human‑driven was the final judgment — the “do I actually accept this, or do I call a lawyer?” moment.
In legal, where the stakes are high, that balance matters a lot: automation for speed and clarity, humans for responsibility and trust.
Love this. The non technical founder journey is so underrated. I think the fact that you understand the pain point deeply from your legal background gives you a massive edge over technical founders who build solutions looking for problems. How did PH go for you?
Totally agree — the non‑technical founder angle is underrated, and having actually lived the legal pain is a huge edge over “solving problems for fun.”
On PH, the launch wasn’t as hot as I thought: just a few comments and upvotes. But surprisingly, this IndieHackers thread has way more engagement than the PH page, which was a nice reminder that real conversations (not just the upvote count) are what actually matter. To me, PH is just one campaign; the real goal is still getting in front of real users.
This is def the post I needed to read today. I'm 15, just launched an accessibility compliance tool, and I've been making the exact mistake of just leading with 'WCAG 2.2 scanner with AI code fixes' and just speaking in buzzwords when people only really care about feel as in 'am I going to get sued and I have no idea where to start.' This mindset for sure changed how i need to think about my pitch. Also the point about shipping before it feels ready is so real tbh I've been tweaking features when I should be talking to users. How long did it take between your first user and the moment you felt confident the product actually solved the right problem? because i feel like im just getting swamped by competitors who do pretty similair things to me but just with superior funding and team management.
Absolutely love this — and at 15, you’re already way ahead of where most of us were.
The “WCAG 2.2 AI scanner” vs “am I going to get sued and I don’t know where to start” shift is exactly the moment EqualDocs clicked too.
On confidence: it wasn’t about perfect features, it was about a small group of real users saying, “this actually stops the thing I’m scared of.” We built the product, then went to market and realized there were already a lot of big names doing similar things — and yes, it felt very non‑competitive at first. But there’s always a niche.
For us, that niche is SMEs, not law firms, even though I’m a lawyer who originally built EqualDocs to help myself and my own clients. You can adjust your angle too — talk directly to the fear, not the specs, and you’ll find your corner.
This really resonated with me, especially the part about reframing the problem around the feeling rather than the feature. I'm building an AI-powered ad creative tool and had a very similar moment — I kept describing it as "automated ad generation" but nobody cared until I started saying "you paste a URL and get ready-to-post ads in 30 seconds." The shift from technical capability to the actual relief people feel was everything.
Your point about the lawyer-to-founder mindset shift is gold too. I come from the technical side but had the opposite challenge — learning to stop over-engineering and just ship something people could react to. Sounds like you and Charles found a great balance between the legal precision and the builder's bias toward action.
Curious about your early user acquisition — are you finding that people come to EqualDocs because they already know they have a contract problem, or are you catching them earlier in the process before they even realize the risk?
Totally feel this — the “relief” vs tech framing is everything.
We’re still balancing legal precision with builder momentum, and early users are not easy to get. I lean heavily on my own network and existing clients to try it out, then we use their feedback to keep adjusting
This hits so many real founder nerves. The way you describe “knowing the problem with perfect clarity but only speaking 10% of the language in technical meetings” is probably the most accurate picture of non‑technical founding I’ve read. Framing EqualDocs around that quiet “I’m about to sign this, and I’m probably missing something” fear instead of abstract ‘AI contract analysis’ makes the product instantly legible, even to people who’ve never hired a lawyer. As a non‑lawyer, a tool that lives exactly in that moment feels like it has a real shot at changing behavior, not just adding another step.
This means a lot, thank you.
The non-technical founder part is the story people usually skip, and it matters. Built a similar AI tool and the hardest part was not prompts or code, it was earning trust, our first 30 user calls were mostly about edge cases and liability, not features. Curious whether your Product Hunt comments today lean more toward curiosity or skepticism around contract accuracy.
On Product Hunt today it’s been a mix, but you can definitely feel that under the curiosity there’s a baseline skepticism around accuracy and trust. Which is fair — with contracts, people aren’t buying speed, they’re buying the feeling that they’re not missing something.
This really resonates, Ningsi. The insight about nobody asking for "AI contract analysis" but instead feeling that fear of "I'm probably missing something" — that's such a fundamental lesson for anyone building AI tools. We're building an AI ad creative generator and hit the exact same wall early on. Nobody was searching for "AI ad generation." What they actually felt was "I know I need to run ads but I have no idea how to make them look good and I don't have time to learn Canva." Once we reframed around that anxiety instead of the technical capability, everything clicked. Your point about the lawyer-to-founder mindset shift is gold too. Covering every edge case vs. shipping fast is a tension I think every technical founder feels in reverse — we want to keep perfecting the code instead of getting it in front of users. Congrats on the PH launch, and curious — how did you handle the trust factor? Legal is such a high-stakes domain. Did early users push back on trusting AI with contracts, or was the pain of doing it manually enough to get them past that?
Same here — that lesson about “nobody asked for the thing you built, they just feel anxious” has been the whole journey.
On trust: early conversations were almost all about that. Most first‑time users treated EqualDocs as a second pair of eyes before or alongside a lawyer, not instead of one — which helped a lot. Over time, what’s worked best is being very explicit about the boundary: the AI surfaces risks, explains them in human language, and suggests edits, but the final judgment is still theirs (or their lawyer’s).
congrats on the launch! as a non technical founder myself this really hits different. the part about feeling like an imposter while building is so real. i think ppl underestimate how much you can get done now with AI tools even without a CS degree. also launching on PH is nerve wracking lol hope it went well for you
Same here — non‑technical founder imposter syndrome is loud, especially on launch day.
Totally agree on the AI part too: this would have been impossible for someone like me a few years ago, now you can get surprisingly far without a CS degree if you’re willing to learn in public. And yes, PH is absolutely nerve‑wracking — but also weirdly fun once the first few comments roll in. Thanks for the kind words!
This really resonates — especially the part about nobody asking for the technical thing you built. They just feel the anxiety of "I'm probably missing something." We had a very similar realization building an AI ad creative tool. Nobody searches for "AI-powered multi-platform ad generation." What they actually feel is: I know I should be running ads, I just don't have time to design them and I can't afford an agency. Once we reframed everything around that moment of frustration instead of the feature list, conversations with early users completely changed.
Congrats on the PH launch! The fact that you built a two-sided platform where both parties can negotiate is a really smart wedge — most contract tools only serve one side. Curious: how are you handling the cold start problem of getting both parties onto the platform?
Totally feel this — we went through almost the exact same messaging shift.
On the two‑sided piece, we’re keeping it really simple for now: one side uploads the contract, does the first pass in EqualDocs, then invites the other party in with a link so they can see the same risks, comments, and suggestions in one place instead of juggling email threads. If the second party clicks the link, disagrees with a term, and edits it, the first party gets a notification to review — and every change is tracked in version history, so both sides can always go back and see what changed and when.
This really resonates. The shift from "thinking like a lawyer" to "thinking like a founder" is one of the hardest transitions I've seen. Lawyers are trained to minimize risk, but building a product requires embracing uncertainty and shipping before it feels ready.
Your point about focusing on the feeling rather than the features is gold. Most founders (technical or not) make the same mistake - they lead with what the product does instead of how it makes people feel. "I'm scared I'm missing something in this contract" is 10x more powerful than "AI-powered clause analysis."
Congrats on the PH launch! How are you handling the balance between legal accuracy and user-friendly language in the AI suggestions?
Yeah, that tension is real — “lawyer brain” wants to be 100% precise, “founder brain” knows you have to ship while things are still messy.
On the EqualDocs side, the compromise has been: keep the analysis strict (treat clauses like a lawyer would), but translate the output into normal language like “here’s what this actually means for you if things go wrong,” plus a concrete suggested edit.
I definitely did the same thing. I tried to build the perfect app before getting paying clients. Even worse, before getting any clients at all. I need to focus and build the minimum needed which someone would see useful. Then when that user sees problems need fixing, then I address and work on the solution. Clients pay for solutions to their problems.
I actually built the first version just for myself.
Then I found it so useful in practice that I started putting my own money to pay for the cost and building Equaldocs, and recommending it to clients as “try this before you come to me” to save on legal fees.
That’s actually really interesting — building it for yourself first probably made it way easier to trust the value.
When you started recommending it to clients, were they immediately open to it or did you have to convince them?
Yeah, scratching my own itch helped a lot with trusting it myself first.
With clients, it was a mix: some were instantly open because it came as a “use this to save some fees before we talk” from their own lawyer, others needed a bit more hand-holding and a first contract side‑by‑side (tool + me) before they fully trusted it.
"Learning to describe a legal problem in engineering terms" is genuinely underrated as a skill. Domain experts who can translate their knowledge into precise product requirements are rare — most technical people can't do it, which is why so many legal tech tools miss the actual workflow. Your unfair advantage is the 10 years of pattern recognition around what small business owners get wrong with contracts. That's the moat, not the code. Good luck with the launch today.
Love this so much — and totally agree, that “translation” skill is its own job.
Those 10 years with small business contracts are basically what EqualDocs is built from; the product is just my pattern recognition turned into software. Thanks a lot for the reminder that the moat is the experience, not the code.
That framing is exactly right - the moat is the experience, not the code. Ten years of reading contracts means you know exactly which clause trips people up, which boilerplate is useless, and where the real risk actually sits. No AI trained on generic legal text can replicate that pattern recognition. Good luck with the PH launch today!
24h later: what actually happened
Little update after launching EqualDocs on Product Hunt and writing this post.
I went into launch day thinking I was shipping “AI contract analysis.”
What the comments and DMs here showed me is something way simpler and much more human:
“I’m about to sign this. I know I’m missing something. I’m scared and I’ll probably sign anyway.”
That feeling is what EqualDocs is really about.
What I learned in 24h
The thing that resonates isn’t “LLMs” or “AI for contracts.” It’s “please don’t let me screw this up before I sign.”
My advantage as a lawyer isn’t fancy language; it’s helping someone decide what actually matters in their specific situation.
Most people don’t want a giant contract platform on day one. They just want one place that helps them make a sane decision before they commit.
The “fear before signing” moment
Almost every story looked the same:
You get a contract in your inbox.
You skim it, maybe paste a clause into Google.
Your stomach drops a bit.
You sign anyway because you’re tired / busy / don’t want to be “difficult.”
EqualDocs is now explicitly aimed at that moment.
The promise I’m trying to build around is:
“You don’t have to sign blind.”
This feedback is already influencing the product:
Copy:
Rewriting the landing page and product copy around “feeling confident before you sign” instead of “AI contract review features.”
UX:
More plain‑language explanations, clearer “here’s what this could mean for you,” and suggested wording you can actually send back.
Roadmap:
Putting multi‑party negotiation and risk clarity ahead of big, heavyweight CLM‑style features.
I’ll come back with another update once those changes are live and I have real numbers on what changed.
If you’ve ever had that “I’m about to sign and I’m low‑key panicking” moment, I’d love to hear what that looked like for you. That’s basically the roadmap now.
This really resonates. The shift from "talking about features" to "talking about the feeling" is something every founder eventually learns — but most learn it way too late.
I'm building in the AI space too (ad creative generation) and had a similar moment. Nobody cares about "13 platform formats" — they care about "I don't have time to make ads for every channel."
The non-technical founder journey is underrated. You bring domain expertise that engineers simply don't have. A lawyer building legal AI > an engineer guessing what lawyers need.
Congrats on the PH launch!
This hits so much of what the last year has felt like.
Totally agree on the “features vs feeling” shift — nobody wakes up wanting “AI contract review,” they wake up thinking “I don’t want this contract to bite me later,” just like your “I don’t have time to make ads for every channel.”
And yes to the non‑technical founder point: domain expertise has been the only real unfair advantage building EqualDocs as a lawyer. Engineers can build faster, but actually knowing where the fear and risk live is a different thing.
Really appreciate the congrats — and wishing you a big win with your ad creative tool too.
Building as a non-technical founder is a brutal lesson in ruthless prioritization. I launched an AI tool last year and my biggest takeaway was to treat your first dev hire as a true co-founder—their early input on architecture saved us months of rework later. How did you approach vetting technical partners versus just hiring a freelancer?
My story is a bit different — my husband works in IT, so Charles (our early technical co‑founder) was already in our network, and I was really lucky to have him on board. Within a few months, riding the whole “vibe coding” wave, we got a lot built.
Looking back, there are definitely architectural and product choices I wish we’d made differently, but that’s just how it goes. As a lawyer, it’s still far from the “perfect” product in my head. Visiting Silicon Valley and seeing how other founders shape their products made me realize there’s still a long way to go on the product side.
Congrats on the launch 👏
That’s impressive, especially as a non-technical founder!
If you want, I can help test your AI contract tool and give a quick, structured feedback report (bugs, UX issues, and improvement opportunities) before more users try it.
Happy to share a review if you’re open!
That’d be amazing, thank you — would really appreciate a structured test from a fresh pair of eyes.
Totally open to your review. Here’s the link: https://equaldocs.com
If you can share bugs, rough edges in the UX, and anything that feels confusing or slow, that would help a lot before more users pile in.
Thanks for sharing the link I’ll run a structured QA test and provide a detailed report.
Before I begin, could you please confirm:
I’ll test for functionality, UX clarity, performance, and overall user experience, and deliver a clear bug + improvement report.
Really interesting! EqualDocs seems similar to Claustar in helping founders avoid contract mistakes. How do you see your approach - focusing on multi-party negotiation and risk flags - compared to a tool like Claustar that guides just one party?
Thanks! EqualDocs is like Claustar for solo checks, but we focus on multi-party negotiations—live risk flags that catch issues for everyone at once (co-founder splits, investor terms).
Claustar great for your side; we make the back-and-forth safer. Complementary tools! What's your top contract headache?
That makes sense - multi-party situations are where things usually get messy.
Biggest headache for me has been vague terms that everyone interprets differently later. How do you handle that in practice?
Also, this space is getting more active - Juro and Ironclad come to mind.
Curious how you’re thinking about differentiation, especially vs Juro’s AI + workflow angle?
You’re so right — vague terms are exactly where things usually blow up later, not on the obvious clauses.
On EqualDocs’ side, the way we handle it today is:
On differentiation:
So in short: they’re the full “system of record”; we’re deliberately starting as a lightweight “system of judgment” for smaller teams who still need to know what they’re agreeing to before any big CLM stack even makes sense.
The product sounds interesting and likely solves a problem many non-lawyers face. But everything needs to be written in easily understandable language. And that's where I have a problem, because there are countless ways to phrase a given situation. How was the AI trained to be prepared for all eventualities and to be trusted to correctly "translate" the contract content into understandable language?
Great question — this is exactly how EqualDocs is designed to work for non-lawyers.
EqualDocs in plain terms:
First, you either tell the AI which law applies (for example, Quebec, Ontario, New York), or the AI spots the governing law clause in your contract.
Based on that local law and your role in the deal, it runs a risk analysis and highlights the clauses that could be problematic for you.
It then rewrites those parts into human-readable language, so you understand what you’re actually agreeing to before you sign.
The best part:
You can chat with the AI in your own language and say what you want, for example:
“I want a 30-day termination notice instead of 90.”
“I don’t want to be responsible for unlimited damages.”
The AI will translate what you said into proper legal wording and add or adjust the clause back into the contract for you to review.
Sounds realy good.
The domain expert vs founder tension is real. I'm a developer building AI tools for game engines and I have the opposite problem - I over-engineer everything and ship too late because I keep thinking like a programmer instead of thinking about what the user actually needs right now. The reframe from "AI contract analysis" to "I'm about to sign this and I'm scared" is a good example of that shift. Took me way too long to learn that nobody cares about your technical architecture, they care about the problem going away.
Totally feel this. As a “lawyer founder” I have the same problem in reverse.
You’re so right: nobody wants “AI contract analysis,” they just think, “I’m about to sign this and I’m scared.” That reframe completely changed how I talk about and build EqualDocs too.
Developers over‑engineer, lawyers over‑lawyer… and the user just wants the fear to go away.
Launching a legal-tech tool as a non-technical founder is a massive hurdle. Most people stop at "I don't know how to build it."
The point you made about describing legal problems in engineering terms is huge. In conversion optimization, we see the same gap: founders describe "features" while users are feeling "anxiety."
Since you're still figuring out where users might be "just signing anyway," have you looked at your own landing page conversion recently?
I’m currently running an experiment where I’m doing deep teardowns of IH founder landing pages to find these exact "silent" conversion leaks. If you want a fresh set of eyes on the EqualDocs flow (beyond the legal side), I'd be happy to run a quick 10-point teardown for you.
You can drop the URL here, or if you want the full report privately, you can grab one here: https://roastmysite.io/go.php?src=ih_equaldocs_legaltech_20260327
Congrats on the PH launch!
That’s an awesome offer, thank you – and totally agree on the “features vs anxiety” gap.
You’re spot on: most non-technical (and legal) founders get stuck at “I don’t know how to build it,” or they talk about “AI contract analysis” while the user is just thinking “I’m scared but I’ll probably sign anyway.”
A fresh teardown on the EqualDocs funnel would be super valuable – especially to catch those “I’m anxious but I bounced” moments I can’t see from the inside. I’ll check out the link and would love your 10‑point roast on the flow.
This is a great example of how AI is changing who can build, not just what gets built.
Non-technical founders used to need a co-founder before they could even test an idea. Now it feels like you can get to a working prototype first, and then decide whether you need deeper technical help.
I also think domain expertise is becoming more valuable in this environment. A lawyer building a legal tool starts with a much clearer understanding of the real pain points than a technical founder exploring the space from the outside.
Curious — did you find that the hardest part was the technical side, or figuring out product scope now that building became easier?
You’re so right – getting a prototype is one thing, getting a scalable product into production is a completely different game.
For EqualDocs it’s been a long road from “this works once” to “this can reliably handle real users,” and there are definitely architecture decisions we now wish we’d made differently. The hardest part, honestly, is that the more you learn, the more you realise what needs to be re‑thought – you start needing professional help, and every new insight forces yet another change in direction.