The Trust Boundary Never Really Disappears

Not every open problem is a consumer app. Some of the most durable ones sit inside compliance, where buyers are careful, reviews are slow and a new tool has to earn trust before anyone looks at features.

This article starts from a public Hacker News post by a founder working on sensitive document workflows in healthcare and legal settings. We will explain what they described, why a gap like theirs is hard to close, and how a founder with the right background can read it as an opening. We are not endorsing the product, and we have not tested it. The point is the shape of the problem.

The sentence

The author asked whether "zero-plaintext" document sharing is useful. In the thread they observed that even privacy tools tend to leave a gap, and put it this way: "So the trust boundary never really disappears." The original is on Hacker News.

A trust boundary is the line between what you control and what someone else controls. When you share a sensitive document, you trust something on the other side of that line: a server, a vendor, a person. A tool can shrink the amount you have to trust. The author's point is that it rarely removes the need entirely. Somewhere, you still have to trust someone.

What that gap looks like for a buyer

For an individual, the gap is a worry. For a hospital or a law firm, it becomes a process. The post describes it in the language of the people who sit in it: security reviews, compliance approvals and vendor trust discussions.

Here is how that tends to play out, in our reading. This is an inference, not a claim from the post.

1. A team wants to use a tool. They find one that looks good.
2. Security asks questions. Where does the data live? Who can read it? What happens if the vendor is breached?
3. Compliance asks for evidence. Certifications, audits, contracts.
4. Procurement asks about the vendor. How long have they existed? Who else uses them?
5. The decision takes months. Not because the tool is bad, but because the boundary has to be re-examined each time.

The founder is not only building a product. They are building a way to get through that process. The author's question to buyers, whether tokenised sharing would change those reviews, is a direct attempt to find out which part of the process the product could shorten.

Why this is a different kind of opening

Consumer problems tend to be loud. People complain about them in public, and a founder can find a thousand posts on the same pain. Compliance problems are quieter. The people who live with them rarely post, and when they do the language is formal.

That has two consequences for a founder.

The competition thins out. Fewer founders read these problems from the inside. Many builders skip them because the sales cycle looks slow.

Background becomes the advantage. A person who has sat through a security review knows which questions come first, which documents are required and who really signs off. That knowledge is hard to get from outside.

If you have worked in regulated industries, you know things that a generalist founder would need a year to learn. The problem is documented, and still being worked out in public.

How to read a compliance problem

Here is a short method for reading posts like this one.

Find the process, not the product

Ignore the tool the author is selling. Look for the steps they name. In this post, the steps are security reviews, compliance approvals and vendor trust talks. Those steps are the real market. The tool is one attempt at serving them.

Note who sits in the review

Ask who is in the room. A security officer, a compliance lead, a procurement manager, a lawyer. Each has a different question. A product that answers only one of them stalls at the next.

Look for the author's own uncertainty

The post asks whether the idea would change the reviews. That is an open question, and it shows where the author is not sure. Uncertainty at the edge of a problem is where a second founder can help.

Weigh the signal honestly

A low engagement post can still name a step that buyers repeat. We would be cautious about size: a post with few replies is a lead, not a market. We are honest about that, and you should be too when you describe it to others.

How to test it without building

Suppose, as a hypothetical, you have worked in hospital IT and you think about this gap. You do not need a product. You need conversations with people in the review.

1. Find three people who have sat in a security review for a document tool.
2. Ask: "When was the last time a tool got stuck in review, and what stopped it?"
3. Ask: "What did you do about it? Did you use a different tool, or a manual process?"
4. Ask: "What did the delay cost?"
5. Ask who made the final decision and what they needed to see.

These are past questions, not hypothetical ones, which is the same discipline we describe in how to tell who will actually pay. If the three people describe the same stuck step, you have found something specific. If every story is different, the problem may be too varied to fit one product.

What to watch out for

Calling it a consumer problem. It is not. The user and the buyer are different people, and the buyer is a committee.

Assuming a feature solves it. A review is about trust, and a feature list is not trust. Certifications, references and time matter.

Moving too fast. A founder who treats a compliance sale like an app launch will be surprised by how long it takes. Plan for the cycle, not against it.

Claiming more than you know. If you have not been in the room, say so. Buyers in this field respond better to honest limits than to confident claims.

Why it belongs on a list of open problems

We keep a habit of reading what founders describe in public, because some of the best problems are not obvious from the outside. We went through the shape of that reading in what 494 founder posts actually say. A regular finding is that the sharpest descriptions are often early: a founder doing discovery in public, with a precise question. This post fits that pattern.

The gap it names is real, and it is old. Privacy tools have improved, and the boundary has moved, but the author's sentence says it has not gone away. For founders who know these reviews from the inside, that is an invitation.

Ask the people who sit in the review.

The takeaway

Compliance has open problems too. A trust boundary moves when a tool improves, but it rarely disappears, and for a hospital or a law firm the leftover gap becomes security reviews, approvals and vendor trust talks. Read the process, not the product, talk to the people in the room, and let your background do the work that a feature list cannot.

How FirstCustomer helps

Problems like this live in public posts that are easy to miss. FirstCustomer reads public posts and returns people describing your problem in their own words, each with a quote, so you can find the people in the review and start from what they actually wrote.