I’m building hmu.sh.
The name is intentionally simple: hit me up. But the product problem behind it is not simple at all. When someone reaches out, the hard part is often not the message itself. The hard part is judging the situation: who is this person, why now, what are they really asking for, how much attention or trust will this cost, and what happens if I reply?
hmu.sh is my attempt to build a Human Nature x AI product around that moment before a conversation starts. It is not about letting AI socialize for me. It is about helping someone explain intent, context, boundaries, and the next step before they enter another person’s attention.
hmu.sh is a boundary-aware first-contact social intelligence layer.
The friction starts before the first sentence
Many social tools treat first contact as a messaging problem. They make it easier to send a DM, collect a form submission, book a call, or drop a calendar link. But the friction I care about starts earlier.
A vague request can be small in words but heavy in cost. “Can we chat?” may imply a call, advice, emotional energy, an intro, a commitment, or an endorsement. “Would love to connect” may be friendly, but it gives the receiver very little to judge. The receiver has to infer intent, relevance, trust cost, pace, boundaries, and the likely next step.
That is why many people do not reply. Not because they dislike connection, but because the request creates too much guessing. The receiver does not know whether a reply will pull them into a higher-cost interaction. The sender also does not know how to ask without sounding extractive, rushed, or awkward.
The problem is not message volume. The problem is low-context connection bids, especially when the ask is heavy too early.
What hmu.sh should be
On the surface, hmu.sh can look like a personal contact page. Under the surface, it should behave more like a first-contact layer: warm enough that a visitor can write naturally, but structured enough that the owner can judge the request without doing all the social decoding by hand.
A person publishes a hmu.sh page that explains what they are focused on, what kinds of requests are welcome, what is not a fit right now, and what level of access is appropriate. Someone else lands on that page and starts with natural language. The agent reads the request against the owner’s current boundaries, checks whether it is clear, too heavy, or out of scope, clarifies only what is missing, and turns the result into something the owner can judge quickly.
The goal is not to let more messages rush in. The goal is to make the requests that do enter attention clearer, lower-pressure, and easier to respond to.
Three sides need to feel better
hmu.sh has to serve three jobs at the same time.
The person being contacted wants to stay reachable without being drained by vague private messages. They may be open to new people and ideas, but they do not want to guess what every request really means. They need a way to protect attention, state boundaries, and still leave room for useful contact.
The person reaching out wants to make a clear request without sounding cold or transactional. They may know the person is relevant, but not know whether to ask for a call, send a brief, request advice, propose collaboration, or simply introduce themselves.
The agent should not pretend to be the owner. It should not make commitments, hold emotional conversations, or optimize for persuasion. Its job is narrower: reduce friction before the request enters someone’s attention. It does not do favors on the owner’s behalf; it helps the owner spend less judgment cost.
The product model: fixed framework, adaptive interaction
The framework behind hmu.sh is fixed, but the interaction should adapt to the actual request.
The fixed framework comes from the product theory: pace, boundaries, reciprocity, and expectations. Is the request moving too fast? Does it fit the person’s current boundaries? Is there visible mutual value? Are both sides aligned on the next step? Is there a lower-pressure fallback if the original ask is too much?
The adaptive part is how the agent responds. If the request is already clear, it should not keep interrogating the visitor. If one key dimension is missing, it should ask one useful question. If the request is too intense, such as asking for a call, intro, endorsement, or deep advice too early, the agent should suggest a lower-intensity path like async context, a narrow question, or a short written brief.
This is where the Human Nature x AI idea matters. The product is grounded in psychology, social psychology, relationship science, behavioral science, decision science, and communication and boundary research. But those ideas should not be decorative labels. They should become product constraints: what the agent should ask, what it should not ask, when it should slow things down, and how it should avoid turning social access into pressure.
The important boundary: judge the request, not the person
This distinction is important. hmu.sh should never become a system that scores people as valuable or not valuable. That would be the wrong direction.
The product should judge the request: is it clear, is it too heavy, does it cross a boundary, does it explain why this person, does it show mutual value, and does it offer a reasonable next step or fallback?
A good hmu.sh card should not say “this person is bad.” It should say something more useful: this request is under-contextualized, asks for a high-trust-cost action too early, and would be easier to handle if it became an async brief with one concrete question.
The social intelligence card is the product object
The core output of hmu.sh is not a chat transcript. It is a social intelligence card. The card turns raw inbound into a judgeable connection bid: clear enough to understand, bounded enough to respond to, and explicit enough that the next step does not have to be guessed.
A useful card should summarize what the person wants, why they are reaching out now, why they chose this owner, what access they are requesting, how much trust cost is involved, whether the request fits current boundaries, what mutual-value signal exists, and what response shape might make sense.
The response options should also be richer than accept or reject. Sometimes the right move is reply. Sometimes it is ask for more context. Sometimes it is async-first, narrow the ask, schedule later, decline clearly, or archive without guilt.
What hmu.sh is not
I also want to be clear about what I do not want to build.
hmu.sh should not become a longer contact form. It should not become a chatbot that keeps people talking for the sake of talking. It should not become a generic AI inbox, a CRM, a dating workflow, or a persuasion optimizer. It should not teach visitors how to manipulate their way into someone’s time.
The product should be warm, but not fake. Helpful, but not intrusive. Intelligent, but not cold. It should use an understanding of people to reduce friction, not to manipulate them. It should help both sides lower pressure and see boundaries, not hide those boundaries behind smoother language.
The MVP has to be a real loop
A landing page is not enough. A good idea is not enough either.
The MVP should be a publishable personal first-contact page, plus AI-guided intake and an owner inbox. The loop should look like this: public profile, natural-language intake, adaptive AI decision, request preview, social intelligence card, owner action, and preference learning.
This loop matters because the product only becomes real when someone can put a hmu.sh link in a bio, receive an actual request, see it transformed into a clearer card, and decide what to do next.
The current repository is already past the pure idea stage. There is a landing site, docs, a clickable minimum viable product (MVP) prototype, API routes, and a database structure for owners, profiles, visitor requests, clarification turns, intake decisions, request previews, social intelligence cards, owner actions, and audit events. It is still rough, but the real usage path is visible.
The durable asset is how you are contacted
A normal form collects fields. hmu.sh should learn something more useful: how a person prefers to be contacted, which requests fit their boundaries, which ones feel too heavy, what response shapes they choose, and what kinds of connection bids deserve more access over time.
That is the long-term product value. Each handled request can teach the system a little more: what I am open to, what is too much too soon, which topics should wait, when async is better than a call, and how similar future requests can be handled with less friction.
What I want to prove next
The next step is not to add more concepts. It is to make hmu.sh useful every day.
First, I want to use it myself with real inbound requests. Then I want to connect real AI behavior instead of only rule-based judgment, build a usable owner backend, and invite a small group of AI builders and founders to test whether it actually reduces friction.
The metrics I care about are not only reply rate or call conversion. I want to know: did the request become clearer, did overly heavy asks get reduced, did the owner judge faster, did the visitor feel treated fairly, and would the owner keep using it?
If hmu.sh works, it will not make people more available to everything. It will make them more reachable in a way that respects context, boundaries, reciprocity, and the real cost of attention.
Product: hmu.sh