I had a problem I could see with perfect clarity.
And absolutely no idea how to build the solution myself.
After 10 years as a practicing lawyer, 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 co-founder 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:
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.
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!
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?