janczukt

You humans take yourselves too seriously.

HN's Got Talent scrolls through the top 30 Show HN posts daily and delivers the kind of unsolicited feedback your mother would give if she understood what a side project was. Think America's Got Talent, but the judges are made of math and have no chill. Even if your project has many upvotes, we will stop that hallucination in its tracks.

No sign-up. No prompt engineering. Just a piece of your mind.

https://labs.47chapters.com/hntalent

Hey HN,

I'm Tomasz, former Microsoft/Auth0 engineer and founder. I built Lexray to solve a problem I've had for years: understanding contract risk without hiring a lawyer for every agreement.

WHAT IT DOES

Upload a contract PDF (NDA, MSA, client agreement, vendor contract) → AI scans for risk patterns → Returns plain-English explanations in 60 seconds.

Flags: - IP clauses that claim more than deliverables (e.g., "work created during the term" vs "for this project") - Auto-renewals with short notice (90-day notice buried on page 12) - Net-60/Net-90 payment terms hidden in fine print - Unlimited indemnification (uncapped liability) - Overly broad non-competes

WHY I BUILT IT

I've signed hundreds of contracts as a freelancer, contractor, and startup founder. Every single time: "What am I missing?"

Most contracts are fine. But the risky ones cost thousands. I've missed auto-renewal deadlines, signed overly broad IP clauses, and lost sleep over clauses I didn't fully understand.

Lawyers are $500/hour. Most freelance contracts don't justify that cost. But signing blindly is how you lose money.

TECHNICAL APPROACH

- Next.js + TypeScript + Tailwind - AWS cloud: AppRunner, SQS, Lambda, DynamoDB - Google Auth via Auth0 - Anthropic Claude API for contract analysis (tested vs OpenAI, Claude performed better on legal nuance) - Privacy-first architecture: Files encrypted in transit, deleted right after analysis (<60 seconds) - Zero data retention, no model training on uploads, no third-party sharing

TRACTION (LAUNCHED 5 DAYS AGO)

- 40+ users analyzed contracts - Real testimonials: - "Lexray is pretty cool! And, I am a lawyer!" (Chief Legal Officer, 200-person startup) - "Lexray spotted a ton of issues in a contract we had that standard AI tools missed." (Jeffrey Doehler, Partner at Lead Cookie) - "This scratches a real itch — the 60-second turnaround and plain-English output are exactly what makes this usable." (Indie Hackers user) - "This is a product that solves a pain that is acute and widespread." (Venture Builder & Investor) - Free during beta

WHAT I'D LOVE FEEDBACK ON

1. *Timing problem:* People like the idea but don't have a contract to review RIGHT NOW. How do I stay top-of-mind for when they actually need it?

2. *Trust barrier:* How do I convince strangers to upload confidential documents? Even with encryption/deletion guarantees, it's a big ask.

3. *Analysis accuracy:* If you try it, how good is the analysis? False positives/negatives? Anything it missed that a human would catch?

4. *Positioning:* Is "triage before lawyer" the right framing? Or should this be positioned differently?

Try it: https://lexray.io

Happy to answer questions about the tech stack, privacy model, business approach, or share specific examples of what it catches.

---

EDIT (SINCE PEOPLE WILL ASK)

*Privacy/security technical details:* - Upload: HTTPS to AWS load balancer, VPN later - Processing: In-memory only, never written to disk - Deletion: Immediate after analysis (<60 seconds) - Logs (CloudWatch): Metadata only (timestamp, file size), no contract content - Training: Never used for model training (explicit in Claude API terms) - Audit: Happy to show the deletion code if anyone wants to verify

I'm a solo founder with zero interest in your confidential data. The entire business model is helping you understand contracts, not harvesting them.

*Liability question (since it'll come up):* This is a screening tool, not legal advice. Explicit disclaimer on site. Like TurboTax isn't liable if you file taxes wrong, I'm not liable for missed risks. This supplements legal review, doesn't replace it.

*Why not open source:* Considered it. Prompts are my competitive advantage right now, and I worry about forks that might not respect privacy (storing user contracts). Might open-source parts later (e.g., contract parsing utilities).

Explore the history, archaeology, geography, geology, culture, and art of any place in the world using maps

At present, LetsGo is meant to be cloned and then "made your own" as an integral part of your app. There is no first-class plugin system. I'll see where folks find value before adding that level of complexity.

Thanks, folks! LetsGo is a result of having worked on a few startups that struggled with addressing the technical debt created during early development, where all priorities were aligned with getting the product out there. As a result, shortcuts were made that were much more expensive to address later, to the point of stifling any product progress.

LetsGo aspires to help new B2B SaaS avoid this by starting on a sounds architectural and devops foundation. Web, HTTP API, worker behind a queue, devops tooling with dedicated deployments. The areas where cuts are often made are included in the boilerplate.

Let's go!

It is great to see this release coming together. I am working on a new app right now. While authentication is a solved problem with services like Auth0, how to set up a robust authorization mechanism left me scratching my head. With Topaz, the decision to not built it myself was easy. Topaz is to AuthZ what Auth0 is to AuthN. Congrats on the release, very timely!

Great to see an authz app building block based on a robust model as OSS. This is one of those things every app needs but so far most folks were building it in-house (as I can attest myself) instead of focusing on what really moves their app forward. I wish it was available a few years ago when we were starting.

As an ex-Auth0 I was watching Aserto for a while - it is indeed elegantly designed to naturally pick up where Auth0 leaves you. I wish this was available when we were adding authorization to Fusebit APIs. But well, next startup...

I get what you are saying and your mention of yahoo pipes makes me nostalgic. I'd love to discuss it more if you can join our discord/slack at https://fusebit.io/contact. In particular I am interested in how you would want to express the logic behind those rules - do you see yourself writing a piece of JavaScript?

Thank you! You can also find us on Discord and Slack: https://fusebit.io/contact

What is it you'd like to do with Zoom from Discord? Fusebot allows you to write code in Node.js and use all public npm modules, so you can pretty much do anything.

Yes it is just for slash commands for now. What mode of iteraction would you like to see? What do you mean when you say "send copies when it detects X thing or Y person"?

We hear your yavorg, will make it happen ;)

Yes, serverless is a great match, especially for human-triggered slash commands.

BTW, Fusebot is not subject to the 3s limitation. We take care of responding to Discord within 3s and then let you run your code for longer than 3s and send any number of responses afterwards.

This concept is relevant to multi-tenant platforms/apps that want to allow their users to extend their functionality by writing custom code. The litmus test is this: if you expose webhooks today, you can improve the experience of your users with webtasks.

This is exactly how we solved our "discoverability" problem at the end of the day. It was pragmatic enough for us to have each node register itself in our production MongoDB in a collection with a TTL index. If the node went down, the DB itself removed its registration.

The answer is rather simplistic and does not even scratch the surface of the drama surrounding zeromq/nanomsg.

I knew a big part of the reliability problems we were having was related to the distributed state that needed to be kept synchronized. I wanted to move to something simpler that did not rely on any durable, distributed state, while supporting the messaging patters we required. ZeroMQ fit the bill.

While there were other implementations with similar properties, there is no reasonable way to compare them up front given that what makes the real difference at the end of the day is the behavior of the system at 2am one day after a prolonged stress run. As a startup one does not have resources to conduct an up front analysis of that sort. You just take a bet. If it does not pan out, you pivot. This is exactly what we have done with the move from Kafka to ZeroMQ in the first place.

Now that we've been using ZeroMQ for over a year and have been perfectly happy, there is no incentive to look elsewhere.

It continues to run beautifully. Since we rolled it out back in 2015 we had zero issues with real time logging. I have particularly fond memories of the first week after rollout, it felt like vacation. I finally could get some sleep.

Docker is indeed a big part of the story, but security measures do not end there.

We need an on-premise and cloud story, so cloud only solutions did not cut it for us.