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 non-technical founder journey is underrated. people assume you need to code everything yourself but the real skill is knowing what to build and for whom — the technical execution is honestly the easier part to figure out.
we built our entire cold outreach automation system in python with zero prior experience in email automation. the hardest part wasn't the code. it was figuring out that agencies would pay $297/mo for personalized outreach instead of the $2,500+ they pay other agencies. that insight came from talking to people, not from writing code.
curious how the PH launch went numbers-wise — did you get more traction from PH itself or from posting about the launch here on IH? in our experience, IH community engagement has driven more real conversations than any single launch event.
Same lesson here. The “hard part” was deciding who we’re really for: founders and small teams who need clarity before signing, not big legal departments. Product Hunt gave a short spike—traffic, a few signups—but the meaningful traction came from IH threads and follow-up DMs where people showed real contracts and we iterated with them. That’s also where we learned what they’d actually pay for (and what they wouldn’t), which mirrors your $297 vs $2,500 discovery. Happy to swap more launch notes if useful.
Hey, I saw your post about ecommerce. I’m building a Shopify store too. I’d like to connect and maybe collaborate.”
Hey, I saw your post about ecommerce. I’m building a Shopify store too. I’d like to connect and maybe collaborate.”
The insight about "I'm about to sign this and there is probably something I'm missing" is gold. That's the exact emotional hook that converts - not "AI contract analysis."
I've been doing free competitor breakdowns for IH founders this week. Happy to do one for EqualDocs if useful - just check my profile and reach out. No pitch, just the analysis with 3 tactics you can steal + your biggest friction point. 12-hour turnaround.
Also curious - how are you handling the cold start problem with both-parties adoption? Are most Quebec beta users initiating or receiving contracts?
🚀
Thanks for this! Yeah, the "did I miss something?" feeling is what gets people to use it—way more relatable than "AI contract analysis."
On cold start: leaning on my old legal network first, then founders doing their own contracts. Two-party adoption is still the hard part, honestly. We're testing whether giving free analysis to the other side helps, but early days.
Hey, I saw your post about ecommerce. I’m building a Shopify store too. I’d like to connect and maybe collaborate.”
wow i love the concept!!! keep pushing!! try using synexiscore to see how its performing!
Hey, I saw your post about ecommerce. I’m building a Shopify store too. I’d like to connect and maybe collaborate.”
Love the concept behind SynexisCore—tools that turn “I think it’s working?” into actual numbers are underrated. For us, the biggest unlock has been seeing where things break, not just guessing, so a performance layer on top of that is interesting. I’ll give it a spin on our side, and appreciate the encouragement to keep pushing.
This is exactly the kind of AI tool I love seeing -- built from real domain pain, not 'let me wrap GPT in a UI.' The insight about people feeling anxiety rather than searching for 'AI contract analysis' is gold. Start with the emotion, not the technology.
Hey, I saw your post about ecommerce. I’m building a Shopify store too. I’d like to connect and maybe collaborate.”
That reframe changed how we built the product, not just how we talk about it. Once we understood the core emotion was "I'm about to sign this and I know I'm missing something" — we stopped optimizing for comprehensiveness and started optimizing for that specific moment. Smaller scope, much sharper product.
That is a strong framing. "Before or instead of a lawyer" forces the real trust boundary into the open immediately. The version I want to test next is basically "would you trust this enough to aim at this role, or only use it as a brainstorming tool?" Same principle, but for career risk instead of legal risk. Open prompts are easier to ask; sharp trust questions are much more useful.
"Brainstorming vs. acting on it" is the same gap. In legal it surfaces as "I'll use this to prep, but I still need a lawyer to confirm" — which tells you exactly where the trust ceiling sits. Once you know that, you can either build toward it or design around it.
That matches what I'm seeing too. PH gave us a credibility spike, but the useful signal only showed up once the prompt was narrow enough for people to answer from lived experience instead of just saying "cool launch." The best question for us has basically been "what makes an adjacent move feel believable vs flattering?" because it surfaces trust objections fast. Next loop I'll probably pair the launch page with 10-15 same-day follow-ups instead of waiting for passive traffic.
Same experience with PH — credibility bump, not real signal. Useful feedback only came when we got specific: "would you use this before or instead of a lawyer?" That surfaced more trust objections in a week than months of open prompts. Active follow-ups are the right call.
Love the way you framed the core pain ("I’m about to sign this and I’m probably missing something"). One conversion tweak worth testing on equaldocs: add a 3-step trust strip right under the hero — (1) upload privately, (2) get plain-language risk flags, (3) choose: self-fix or lawyer review. Legal buyers usually need to see both speed + safety in one glance.
If useful, I can do a compact teardown of your signup flow (first-screen clarity, trust proof, CTA order) and share only concrete fixes. I’m running a US$1 founder pass right now: https://roastmysite.io/go.php?src=ih_equaldocs_truststrip_20260330_0752_hv
Hey, I saw your post about ecommerce. I’m building a Shopify store too. I’d like to connect and maybe collaborate.”
Love that 3-step trust strip idea—will A/B it under the hero. A compact signup teardown would help; happy to take the US$1 founder pass. Let me know what you need from me (latest hero copy? current funnel stats?) to get started.
Perfect — fastest way:
I’ll send back a compact teardown with only prioritized fixes (no fluff), plus exact copy swaps.
Founder pass link (US$1): https://roastmysite.io/go.php?src=ih_equaldocs_followup_20260331_2029_hv
How hard was it to find your technical adviser Charles, and since he is not from the legal side of things and both of you speak different languages lol, one mostly in code and one in legal talk, how do you understand yourselves ? I love this idea by the way
Hey, I saw your post about ecommerce. I’m building a Shopify store too. I’d like to connect and maybe collaborate.”
Found Charles via a trusted intro after I asked for “a lawyer who likes APIs.”
How we click: I translate features into user stories/data flows; he turns them into risks/obligations; we keep a shared glossary. We do fast demo + “what if” drills, then turn answers into tickets/tests. Treat legal like a performance constraint—design with it from the start, not after launch.
Do not stop thinking as a lawyer! You are the perfect stakeholder to gather requirements from. Start building your backlog instead :)
On it—lawyer hat staying on. I’ll start drafting the backlog and reanalyze.
this is a great example of domain expertise being the moat. you spent 10 years seeing contracts go wrong in very specific ways — no amount of technical skill replaces that pattern recognition. i'm building something similar in a completely different space (automated outreach for agencies) and the thing that makes it work isn't the code, it's knowing exactly which SEO problems agencies actually care about vs which ones are just noise. the non-technical founder story gets a bad rap but honestly the best products i've seen on IH come from people who deeply understand the problem and found the right technical partner. congrats on the PH launch.
Totally agree—the sharp edge is that pattern recognition from years of “I’ve seen this movie” moments. Tech is the enabler; the moat is knowing which fires actually burn the customer. Love that you’re doing it in outreach for agencies; separating real SEO pain from vanity noise is half the battle. Thanks for the PH congrats—here’s to more domain-driven wins on IH.
This is a great point.
I feel like a lot of people underestimate this part until they actually try building something.
Right—once you’re in the trenches, you realize the hard part isn’t code, it’s judgment. The edge is knowing which problems are worth solving and which to ignore.
This line really stood out to me: "Nobody asks for AI contract analysis. What they actually feel is: I am about to sign this and there is probably something I am missing."
That is such a good insight and applies to so many products honestly. People do not buy features, they buy relief from anxiety. I have been building an AI tool in a totally different space (ad creatives) and the exact same thing is true — nobody searches for "AI ad generation." They search for "my ads are not converting and I do not know why."
The fact that you built this as a non-technical founder with a domain expert background is actually a huge advantage. You understand the actual pain better than any engineer ever could. The technical stuff can always be learned or hired. The deep understanding of what makes a contract dangerous cannot.
Curious how the PH launch went — did you get much traction from it? And how are you thinking about pricing? Legal tools seem like they could command a premium since the alternative (actual lawyers) is so expensive.
Exactly—people pay to make the stomach-knot vanish, not for “AI.”
PH: nice credibility spike and signups, modest direct conversions; better results from targeted GC/ops/founder communities.
Pricing in one breath: anchor vs. outside counsel, keep it predictable. Starter (capped volume, core flags), Pro (higher volume, Drive/Slack, suggested redlines, audit trail), Enterprise (SSO, data residency, SLAs, optional human review). Spotlight one hero plan and keep a “lawyer fallback” path to feel safe.
Happy to trade channel notes if you want.
The both-parties angle is interesting but it creates a cold start problem that single-sided contract tools don't have. If I'm the one proposing the contract, I need the other party to also adopt your platform for the full value to kick in. How are you handling that? Are most of your Quebec beta users initiating the contract or receiving it?
We designed it to work one-sided first, so there’s value even if the counterparty never signs up: you upload/flag/redline and send a normal link/PDF; they can view/respond without an account. If they do click “reply,” we give them a light, no-login lane to comment or propose changes.
To ease the cold start we:
Default to “you initiate” use cases: you’re drafting or reviewing an inbound.
Auto-build a clean, shareable summary + risk flags they can read on any device.
If they create a free seat, we unlock side-by-side versions and audit trail, but it’s optional.
In Quebec beta, ~70% of sessions are initiated by our users; recipients are mostly external and only a minority create accounts, which is fine because the sender still gets the workflow and assurances.
The "second pair of eyes" positioning is really smart. I've worked on dev tools where the same trust problem exists — people won't use something that claims to replace their expert, but they'll absolutely use something that helps them show up to the expert more prepared.
One thing I'm curious about though: how are you handling the jurisdictional complexity? Contracts in Quebec vs Ontario vs a cross-border US deal have wildly different risk profiles for the same clause. Are you training on jurisdiction-specific case law, or is it more of a general risk flagging approach? Because that's where I'd imagine the moat really gets built — generic "this clause looks risky" is table stakes, but "this clause is risky specifically because of Quebec's Civil Code Article X" is where a lawyer-founder has an unfair advantage over pure tech competitors.
Also your point about shipping before it feels ready as a lawyer is so relatable from the engineering side. We're trained to handle every edge case. The muscle of saying "good enough, ship it" never stops being uncomfortable.
Totally agree on the “second pair of eyes” frame—trust is additive, not replacement.
Jurisdiction handling: we segment by governing law + counterparty location up front. Base model does general risk flagging, then a rules/precedent layer keyed to that jurisdiction (e.g., civil-law quirks in Québec, UCC/indemnity defaults in US states, ON employment carve‑outs). We’re not claiming exhaustive case-law coverage yet, but we surface “because of X rule in Y place” when we have high confidence; otherwise we still flag and tag it as jurisdiction-sensitive so the lawyer knows where to dig.
The discomfort of “ship it before it’s perfect” never goes away—same muscle engineers and lawyers both have to train.
Good timing on the Product Hunt launch — I just launched CoachAutomate there too today. How did you build up your PH following before launch? I'm starting from zero and curious what actually moved the needle for you.
Starting from zero, the only things that mattered were: 1) a short “here’s what I’m building and why” post on IH a week prior, so people recognized it on launch day; 2) DM’ing a small list of founders I’d already helped with contracts to ask for honest comments, not upvotes; 3) a 2-minute Loom showing the “one feeling” the product resolves. Everything else (timing, badges, hunter) was noise compared to those warm, specific asks.
That's really helpful — the warm specific asks angle makes sense. The Loom idea is interesting too, hadn't thought about showing the "feeling" rather than the features. Did you find that the IH post a week prior needed to be polished or did a rough draft work fine?
A rough, honest draft works best on IH—people smell polish and disengage. What mattered for me: a clear hook (“why this, why now”), 1–2 real screenshots/GIFs, and a specific ask (“tell me if X is confusing”). Since you already researched, your quick draft is enough; just add a Loom for the “feel” and a single question for feedback.
That's the clearest breakdown I've seen on this — "why this, why now" as the hook makes total sense. I'll keep it rough and add one specific ask. Really appreciate you taking the time to break it down like this.
Hey, I saw your post about ecommerce. I’m building a Shopify store too. I’d like to connect and maybe collaborate.”
Thanks for reaching out — CoachAutomate is focused on the coaching niche specifically so Shopify isn't really in our world, but good luck with the store!
The insight about nobody asking for 'AI contract analysis' is gold. I've seen this pattern across every AI tool I've built or used — the technical description of what the product does is almost never what makes someone try it. The feeling you described ('I'm about to sign this and I'm probably missing something') is exactly the kind of emotional hook that converts. Most builders in AI describe their product by what it does technically rather than what moment of anxiety it resolves. Curious about your inference costs — contract analysis can get token-heavy fast, especially with longer documents. How are you handling that on a per-user basis without it eating into margins?
Yeah, “AI contract analysis” is not what anyone is actually buying—they’re buying peace of mind before they sign. On costs: we don’t throw the whole doc at the heaviest model. We front-load cheap passes (structure, clause spotting, jurisdiction/risk tags), then only run deep analysis on the parts that matter. Prompts are tight, reuse is cached, and we nudge users to one “golden” review per deal instead of chatty back-and-forth. That keeps margins sane while still catching the “looks fine but isn’t” clauses.
Great story Ningsi. The insight about selling the feeling ("I'm about to sign this and probably missing something") instead of features really resonates.
I'm building something similar in a different space — a free financial health scoring tool for digital agencies. Same pattern: agency owners don't wake up thinking "I need to check my Days Sales Outstanding." They think "things feel tight but I don't know why." That reframe changed how I describe the tool completely.
Curious how you're finding your first users beyond Product Hunt? I'm at the very early stage (cold emailing accountants who serve agencies as a distribution channel) and would love to hear what's working for you.
Good luck with EqualDocs!
Love that framing; the feeling is the real hook. After Product Hunt, the users who stuck came from slower channels: founders I already knew, incubator cohorts, and IH threads where people sent real contracts. Each convo ended with “try it on one contract, see if it flags anything” — low-friction trust builder. Cold channel that worked: partnering with fractional GCs/accounting firms who already triage contracts for SMEs; they forward the “does this look fine?” questions to EqualDocs. Your accountants-as-channel idea is spot on. One real pain + one safe first use is what kept our earliest users around.
love the non-technical founder angle. honestly the best products i've seen come from people who understand the problem deeply but had to figure out the tech side as they went. domain expertise beats technical skill for knowing what to build. how did you handle the initial user trust issue? legal tools feel like they'd have a higher bar for trust than most SaaS — people need to feel confident the output is actually reliable before they'd use it on real contracts.
Trust bar was the real hurdle. I used it first on my own client matters, then had a few friendly founders run their real contracts through it while keeping their lawyers in the loop. The rule: documents stay private (not training data), every explanation links back to the clause so they can verify, and AI suggestions are there to prepare you—not replace counsel. Seeing it catch one “looks fine but kills you in Quebec” clause was the moment people started trusting it on real deals.
love the non-technical founder angle. building something in a domain you actually understand beats being a technical founder building in a domain you don't.
i'm technical but the product that's getting traction isn't my fanciest code — it's a simple cold outreach service for agencies. scan their site, find real SEO problems, email them a personalized pitch. $297/mo.
the tech is basic (python scripts, gmail SMTP, cron jobs). what makes it work is that i spent weeks talking to agency owners before writing a single line of code. same as you — domain knowledge first, code second.
how did your PH launch go traffic-wise? curious what the conversion funnel looked like.
Totally with you: domain fluency beats fancy stacks. Our PH launch was a clean spike—lots of curious clicks, light on qualified signups. The real funnel started after, when IH folks DM’d with actual contracts and we could show value in their context; those conversations converted far better than the launch-day traffic. If I mapped it now: PH = awareness, IH = intent → feedback → paid. The pattern echoes your $297 service: simple tech, priced for a clear pain, and every win came from talking to the right people before touching code.
Really honest and relatable post. It’s refreshing to see the real side of building as a non-technical founder, not just the wins but the doubts and learning process too. Launching on Product Hunt is one thing, but actually building something useful from scratch without a technical background takes serious courage. Great reminder that you don’t need to be a developer to start, you just need persistence and a clear problem to solve
Appreciate that. Being non-technical forced me to ship the messy versions and learn out loud instead of hiding behind “one more feature.” Product Hunt was a splash; the courage part was the weeks after, sitting with users and fixing the rough edges without a code safety net. You don’t need to be a dev to start—you need a real problem, the willingness to show ugly drafts, and enough persistence to keep tightening the screws after launch.
What you described about the PH launch being quieter than expected, but IH bringing deeper conversations, matches what I've seen too. I've launched several AI tools and the pattern is consistent: PH gives you a visibility spike, but IH is where you find people who actually have the problem you're solving. The domain expertise you bring as a lawyer is a real competitive moat — non-technical founders with deep domain knowledge often build more defensible products than pure engineers copying existing tools.
We saw the same thing: Product Hunt was a nice spike, but the real learning came from 1:1 threads on Indie Hackers where people showed us their actual contracts. As a lawyer founder, that’s the only way we caught the “this clause looks fine but is risky in Quebec” moments that generic AI tools miss. The moat isn’t the model; it’s knowing which 5% of issues make or break a deal and shaping the product around those. Happy to trade notes if you’re iterating on your next launch.
The part about your CTO speaking in "models, pipelines, and inference costs" really hit home. I'm a solo dev building a macOS menu bar tool that tracks AI token usage in real time (TokenBar), and the #1 thing I keep hearing from other builders is they had no idea how fast API costs stack up until they actually see the numbers broken down per call.
For a legal tool where you're probably running longer context windows to get accurate clause analysis, that cost visibility seems especially critical. Curious — are you eating the inference costs on the $9/mo plan, or is there a usage cap? Because at that price point with legal-length documents, the margins must be razor thin unless you've done some serious prompt optimization.
Also, your point about selling the feeling instead of the feature is something I wish I'd internalized sooner. I kept pitching "token counter" when what people actually feel is "I have no idea if I'm burning $50/day or $5/day on AI and it's stressing me out." Same lesson, different domain.
You put your finger on the exact issue. When my co-founder starts talking in models, pipelines, and inference costs, what I’m usually translating back is: does this still make sense for a small business at $9/month, or are we building something clever that breaks the second people actually use it.
Right now the pricing is intentionally early-stage. We do have to be careful on prompt design, document flow, and what actually needs the heavier analysis vs what doesn’t. Otherwise legal-length docs get expensive fast. The goal is not to meter people into anxiety, but we also can’t pretend inference is free.
And yes, your TokenBar example is the same lesson. People rarely buy the feature itself. They buy relief from the stress of not knowing what’s happening underneath.
What a great product! I had an issue with a landlord due to this specific issue. I wish there would have been something like this.
btw, what are some of the legal things you had to take into account when creating this? Im guessing uploading a contract might come with some? Sorry, im an engineer so Im kinda dumb in this area :P
That was one of the biggest things we had to think through. Contracts are usually confidential, so from day 1 the rule was: user documents are not training data, and the product has to help people understand risk without drifting into specific legal advice. The problem is simple: legal work for SMEs is slow, inconsistent, and expensive, but that does not mean people should have to give up privacy just to get a second pair of eyes on a contract. Happy to share more of the thinking if useful.
Love this story, Ningsi. The transition from domain expert to founder is fascinating, especially learning to describe legal problems in engineering terms. That translation skill is actually one of the most underrated advantages non-technical founders bring — you understand the user's language natively because you lived it.
I had a similar realization building my indie app. The hardest part wasn't coding — it was not having the right people around to pressure-test decisions. What changed everything was building a small network of other solo founders through communities like IH who could give honest feedback. Even 2-3 people who genuinely understand the founder journey makes a huge difference between shipping something real and spiraling in self-doubt.
To your question — yes, absolutely. I signed a freelance agreement once without properly reviewing a non-compete clause that was way broader than expected. Your insight about the real problem being fear rather than legal complexity really nails it.
How has the IH and PH community response been so far? Are you finding that legaltech founders connect and support each other, or is it still a pretty isolated space?
The translation gap is the real work. Coming in as a lawyer, I had the domain fluency — I knew exactly what made a contract dangerous. Describing that in engineering terms took almost as long as building the product itself.
What non-technical founders actually have is precision about the user's pain, which turns out to be harder to fake than technical skills. The IH community is where I've gotten the most useful pressure-testing on that — two honest replies here have been worth more than entire weeks of solo iteration.
The shift from "AI contract analysis" to "I'm about to sign this and I'm hoping it's fine" is a great insight. That gap between what founders think they're selling and what users actually feel is where most products get stuck.
I had a similar realization building something in a completely different space. I kept describing what my tool does technically. Nobody cared. When I started describing the feeling - "you think you know where your time goes, but you don't, and the gap is uncomfortable" - people got it instantly.
Your line about learning to stop thinking like a lawyer when building is interesting. The same thing happens in reverse - engineers building for non-technical users keep defaulting to how the system works instead of what the user feels. The translation problem goes both ways.
Good luck with the PH launch!
Thank you for your comment
Congrats on launching! As someone who also built an AI tool as a mostly-non-technical founder, the "you don't have to understand every line of code" realization was huge for me too.
Curious — how are you thinking about the go-to-market side? Legal feels like a trust-heavy space where word of mouth matters more than typical SaaS growth playbooks. Are you targeting solo practitioners or firms?
That realization about not needing to understand every line of code is the exact moment building starts to feel possible. I had to overcome the opposite "disease"—wanting to over-lawyer every scenario the same way devs want to over-engineer edge cases.
We’ve found that in high-trust spaces like law, traditional enterprise playbooks usually fail. We target SMEs directly and price cheap specifically for word-of-mouth. It’s about being a "second pair of eyes" before the $450/hr lawyer clock starts. Who has been your best early adopter?
This resonates a lot. We're building something in a similar vein, helping expat freelancers in Germany understand their tax letters from the Finanzamt in plain English. The parallel to your situation: the people who most need the tool are the ones who most distrust it initially, because the stakes feel too high to trust an AI with. Your observation about emotion is exactly right. Nobody says 'I need contract analysis.' They say 'I'm about to sign this and something feels off.' For us it's 'I got a letter from the German tax authority and I have no idea if I owe money or if they owe me.' The real product is reducing that specific fear, not the feature list underneath it. Good luck on PH today.
Translating a German tax letter sounds exactly like translating legal boilerplate! The sheer anxiety of reading something and not knowing if you're suddenly going to owe money is identical to the fear of missing a hidden clause.
The "distrust" paradox you mentioned was actually our biggest hurdle too. Our breakthrough was actively positioning EqualDocs as a "second pair of eyes" to use before calling your lawyer, rather than a total replacement. It instantly removed the liability anxiety because users finally felt they were coming into the conversation prepared instead of taking a blind risk. Good luck out there!
ok the part about nobody asking for "AI contract analysis" genuinely stopped me mid-scroll. because i've been stuck on the exact same thing in a totally different space.
i'm building a job search tool and kept pitching it as "ATS resume optimization" for months. crickets. nobody cares about that phrase. what they actually feel is "i applied to 100 jobs and got ghosted, what am i doing wrong." once i started leading with that feeling instead of the feature name, people immediately got it.
also really curious about your dynamic with your technical co-founder. i'm on the opposite side (engineer, zero legal/business instincts) and i keep catching myself overbuilding instead of shipping. like you said, lawyers want to close every gap. engineers want to handle every edge case. same disease, different symptoms lol
how's PH going so far today?
“Same disease, different symptoms” is the perfect way to phrase it! As a lawyer founder, my natural instinct is to over-lawyer every scenario the exact same way devs want to over-engineer edge cases. The only way my CTO and I survived was treating each other as thought partners—shipping before we felt completely safe.
That resume pivot you made is brilliant, by the way. You stopped selling the feature and started selling the relief.
As for our Product Hunt launch—it’s actually quieter than we expected! But it forced us to stop doing "launch theater" and focus entirely on deeper, one-on-one conversations here on IH instead. Honestly, a blessing in disguise!
This was a really honest breakdown of what it’s like as a non-technical founder. The biggest takeaway for me is that the hardest part isn’t the tech — it’s translating your domain knowledge into something engineers can build.
Translating 10 years of legal scar tissue into a spec for my CTO was easily the most painful part of the early build! As a lawyer founder, the natural instinct is to over-lawyer every feature the exact same way devs want to over-engineer them.
Our biggest lesson was learning to treat early technical partners as thought partners, not just task takers. Instead of throwing a massive "legal workflow" spec over the wall, we started doing very small test projects to see how they handled the tradeoffs. Glad the breakdown resonated!
What did you do to get your first uers? offer a beta? discounted pricing? I am in the early stage of launching a new security tool and looking for ideas.
Early users are incredibly hard to get, especially in high-trust spaces like security and law.
Most of our absolute first users simply came from my existing legal client base. I literally told them to "try this tool first before paying me" to save on their legal fees. We just sat and watched where they got confused, and adjusted the product from there. We eventually used a very cheap pricing tier ($5/month plus some initial free contracts) simply to remove all friction.
You don't necessarily need a flashy discount hook right now—you just need a handful of people willing to let you watch them click around your tool!
This resonates more than you'd expect from a live streaming founder.
I'm non-technical too. My devs built the MVP, I designed the product and lived the problem. The hardest part wasn't finding engineers, it was translating 4 years of creator frustration into a product spec that actually made sense to them.
Your line about 'describing a legal problem in engineering terms' is exactly it. I had to learn to describe emotional pain points (algorithm bias, broken discovery, unfair cuts) as technical requirements. That gap between what you feel and what you can build is real.
Also, the fear insight is sharp. Nobody asks for 'creator monetization tools.' They feel: I worked hard this month and made nothing. That's the thing we're solving.
Good luck with the launch. Non-technical founders building real things is underrated.
It’s wild how universal that translation gap is. We found the exact same thing in legal tech—users don't want "AI contract analysis," they just have a deep fear of missing a trap before signing.
Being non-technical actually ends up being an advantage here. Because we can't write the code, we can't over-engineer—we're forced to build exactly what solves that root emotional pain. Good luck with the launch!
100%, the constraint becomes the feature. When you can't build everything, you're forced to build the right thing. The emotional pain IS the product spec. Most over-engineered tools fail because the builder fell in love with the solution before they understood the fear. Sounds like you didn't make that mistake. Thank you for the well wishes and good luck with your venture as well!
The part about reframing from features to feelings really resonates. We had the exact same breakthrough building an AI ad creative tool — nobody was searching for "AI-powered ad generation platform," but tons of people were saying "I know I should be running ads but I don't have time to learn Canva" or "I spent $500 on a designer and the ads still didn't convert." Once we stopped describing what the product does technically and started describing the anxiety it removes, everything clicked.
Your insight about the lawyer-vs-founder tension is something I think about a lot too. In our case it's the engineer-vs-founder version — the instinct to cover every edge case and make the architecture perfect before shipping, versus just getting it into people's hands and iterating. Still working on that muscle. Congrats on the PH launch — the "both parties on the same platform" angle is really smart positioning. Most legal tools only serve one side of the table.
thx for you comment agian
Hi Ningsi, As a ecom and SaaS portfolio holder, we use lawyers all the time for contracts. We have been using some other tools so far so I found yours interesting to use which I will give it a test with the team. On the other hand, I checked your website and your pricing models are VERY cheap, so I’m wondering how you’re planning to monetize this and scale this business as I’m sure you only rely on organic or mouth to mouth marketing with this pricing models. Also connected with you on Linkedin.
Thanks for connecting! You hit the nail on the head regarding pricing. We are definitely much cheaper than the big enterprise names, and that is completely intentional right now to get early user feedback. We actually started at $5, moved it to $9/month, and still give everyone 5 free contracts just so they can properly test it. Word of mouth is exactly what we are relying on right now.
Please push it to its limits with your team, I'd love to hear your honest feedback!
The "stop thinking like a lawyer, start shipping" insight is real and cuts across domains. We're running ClipFactory entirely with AI agents — and the same muscle applies: the AI wants to handle every edge case before shipping, but the market feedback loop is far more valuable than complete coverage.
On your question — yes, signed a SaaS vendor contract without catching an auto-renewal clause that locked us in for another year. The thing nobody told me: the most dangerous clauses are the ones that feel like boilerplate. They're written to not be read.
The "fear before signing" framing is exactly right. That's the emotional trigger to design around, not the legal complexity. Good luck with the PH launch today.
The "boilerplate trap" is exactly what we kept seeing in our beta! Auto-renewal and liability shifts are literally engineered to look boring so you skip them, which is where that exact fear comes from.
And you're spot on about the AI side—getting the LLMs to stop over-lawyering every tiny edge case and just flag the actual "gotchas" was our hardest technical hurdle. Good luck with ClipFactory! Market feedback definitely beats complete coverage every time.
One thing I underestimated while preparing a Product Hunt launch is how much the prelaunch page matters before launch day. A clean first comment, an obvious value proposition, and one discussion prompt that invites real feedback do more than a lot of launch-day theater. People decide very quickly whether they trust what you are building, especially when the founder is translating a domain problem into product language for the first time.
You're completely right about launch-day theater versus actual trust-building. We experienced this exact friction when we launched EqualDocs.
Our Product Hunt launch was actually much quieter than we expected, specifically because we struggled to translate a high-stress domain problem (legal liability) into a punchy SaaS value prop on our pre-launch page. But that quiet launch ended up being a blessing because it forced us to stop doing "theater" and start having deeper, one-on-one conversations here on Indie Hackers instead. We learned quickly that for a complex domain like law, an obvious value prop isn't enough on its own—people have to feel like you understand the anxiety of their problem before they'll trust your product language. Nailing that first comment and inviting real feedback is exactly how you prove that.
This really resonates, Ningsi. The insight about selling the feeling instead of the feature is something I had to learn the hard way too. I'm building an AI-powered ad creative tool, and early on I kept explaining the tech — how the AI analyzes your landing page, generates platform-specific creatives, etc. Nobody cared. But when I started saying "you know that moment where you need ads running but stare at Canva for 2 hours and give up?" — suddenly people got it instantly.
Your point about the lawyer-to-founder mental shift is so real. In my case it's the engineer-to-founder version: I want to cover every edge case and make the architecture perfect before shipping, but users just need the core problem solved. Shipping before it feels "ready" is genuinely the hardest muscle to build.
Congrats on the PH launch — the two-sided contract platform angle is really smart. Curious: how are you thinking about the go-to-market? Are you targeting the small business owners directly, or going through the lawyers/accountants who advise them?
thx for you comment again
You’re getting unusually high-comment engagement for a founder story, so if your goal is first paid users fast, I’d run a tiny paid-intent test on this exact audience today:
Track only two numbers for 48h: checkout starts and paid completions. Keep the winner copy, kill everything else.
If useful, I can run a quick 10-point conversion teardown of EqualDocs and give you the highest-friction fixes first:
https://roastmysite.io/go.php?src=ih_equaldocs_paidpilot_20260328_1047_usd_presell_hv
good idea
This really resonates, Ningsi. The insight about nobody asking for "AI contract analysis" — they just feel that gut-level fear of missing something — is such a universal truth in building AI tools. I'm working on an AI ad creative generator and had the exact same realization. Nobody searches for "multi-platform ad asset generation." What they actually feel is: I know I should be running ads, but I don't have a designer, I don't have time, and I'll probably mess up the dimensions anyway. Once we started talking about that feeling instead of the feature set, everything clicked.
Your point about the lawyer-to-founder mindset shift is really interesting too. The instinct to cover every edge case before shipping is probably the #1 thing that slows down domain-expert founders. How did you decide what was "good enough" for your Product Hunt launch? Was there a specific moment where you just said "ship it" even though the lawyer in you wanted to add more safeguards?
Thanks for multiple commenting
The reframe you landed on — "you shouldn't need a lawyer on call to know what you're agreeing to" — is the exact positioning that makes this legible to a non-lawyer audience instantly. That's not an obvious thing to get right.
Building multiple SaaS tools myself, the hardest problem I keep running into is exactly what you described: translating deep domain knowledge into something an engineer can implement faithfully. The signal loss that happens between "I know what this feels like in practice" and "here is the spec" is brutal. You having both — the domain knowledge AND the scar tissue from watching contracts go wrong — means you're probably the only person who can build this specific version of the product correctly. An engineer guessing at what SMBs are scared of would build the wrong thing.
One thing from your 24h update I think is worth doubling down on: the detail about early users treating EqualDocs as a "second pair of eyes before or alongside a lawyer, not instead of one" is actually your clearest trust signal. That framing removes the liability anxiety for cautious users ("it's not replacing my lawyer, it's helping me come into that conversation prepared"). It might be worth making that explicit in onboarding — not as a legal disclaimer but as a confidence framing: "most users review with EqualDocs first, then take any remaining questions to their lawyer."
The hardest part of building in a high-stakes domain isn't the AI accuracy — it's convincing users it's safe to trust it enough to act. That framing solves it without needing to over-promise on the AI.
Spot on regarding the "signal loss" translating domain knowledge to code. It's brutal.
The "second pair of eyes" framing honestly wasn't a planned strategy—it's just what we observed. Our earliest users used EqualDocs exactly like that, just to triage the contract before starting the $450/hr lawyer clock. Making that explicit in onboarding definitely removed the liability anxiety.
Strong build story — and your point about “fear before signing” is exactly the right emotional wedge.
If you want one fast experiment for this week: run a 3-message onboarding split on your homepage.
A) “Spot risky clauses before you sign”
B) “Negotiate contracts 2x faster with less back-and-forth”
C) “Know what you’re agreeing to in plain English”
Track only 2 numbers for 7 days: signup-start rate and completion rate. Keep the winner, kill the rest.
If useful, I can do a quick 10-point conversion teardown of EqualDocs (headline, trust blocks, CTA friction, first-screen clarity) so you can test improvements immediately:
https://roastmysite.io/go.php?src=ih_equaldocs_followup_20260328_0542_usd_presell_hv
Thank you , will check
This really resonated with me. I just launched my own app on Product Hunt last week — an iOS alarm clock that wakes you up with spoken motivational quotes. Completely different space from legaltech, but that feeling you described of "I can see the problem clearly but have no idea how to build it" hit home hard.
The insight about nobody asking for "AI contract analysis" is gold. Same thing happened to me — nobody searches for "motivational alarm clock." They just feel the dread of waking up and want mornings to feel less terrible. The moment I stopped leading with features and started with the emotion, everything clicked.
Congrats on the PH launch and shipping with a co-founder from a totally different world. That takes real trust. Rooting for you both.
Love this — and your alarm app actually sounds awesome.
Same here: nothing clicked for EqualDocs until it was about that quiet “I’m about to sign and I’m probably missing something” feeling, not “AI contract analysis.” The way through has been: let AI do the heavy lifting, but keep humans in charge of the final call.
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.
You nailed it — your bookmark story is the same pattern.
EqualDocs only started to click once it was about that quiet “I’m about to sign and I’m probably missing something” moment. And yes, being non‑technical weirdly helped; I couldn’t hide behind “one more feature,” so I had to ship early and learn in public.
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.
Thanks so much — that would be incredibly helpful.
Quick context so your report is useful:
Main target users: small and mid-sized businesses and solo founders, not law firms.
Key things to focus on: upload → risk review → AI suggestions → share/negotiation flow (that’s the core loop).
Known rough spots: onboarding clarity (explaining what to do first), some UI heaviness around multi-step review, and making it clearer what the AI can/can’t be trusted with.
Really appreciate a structured QA pass on functionality, UX clarity, performance, and overall “first-time user” feel.
Hi, thanks again for the detailed context it really helped guide the testing.
I’ve completed a structured QA review focusing on the full user flow (upload → risk review → AI suggestions → sharing), along with first-time user experience, UX clarity, and performance.
I’ve documented:
You’ll find everything clearly structured in the report with explanations and supporting screenshots.
Let me know if you’d like me to run another round after fixes or go deeper into specific areas.
Hello could you please send me your gmail so i can send what i tested for you
Great Thx, you can just send to [email protected]
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.
Good luck! 🍀
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.
This comment was deleted 8 days ago.