beechwood

Hi HN, I’m Sarah. I built InboxNest because I run several small projects and their support email had become a mess of aliases, forwarding rules, providers, and separate inboxes. It technically worked, but I was checking too many places and mixing customer conversations with unrelated email.

Most support tools I looked at felt designed for teams with ticket queues, assignments, SLAs, and a lot of configuration. I’m a solo operator. I wanted one place to answer customer email for every project without turning support into another system I had to manage.

InboxNest lets you create branded addresses across multiple domains and manage them from one inbox. Replies go out from the same address that received the message. If a domain doesn’t already use email, InboxNest can receive its support mail directly through MX records. If it already uses Google, Microsoft, or another provider, you can forward only the support addresses you want and leave the rest of the domain’s email alone.

It also includes a customizable website contact widget and a hosted contact page. Messages submitted through either become regular email conversations in the inbox, and the customer receives replies by email.

The application is built with php, mysql, nginx, Alpine, Tailwind, and Postmark. The inbox UI was actually the straightforward part. Most of the work went into the mail plumbing and trying to prevent one customer from damaging deliverability for everyone else.

Connected domains use DKIM and custom Return-Paths. Postmark webhooks are authenticated, idempotent, and recoverable after failed processing. Outbound sending has separate limits at the address, domain, and account levels. Hard bounces suppress the recipient for that domain, and spam complaints or unusual sending can automatically pause outbound mail without stopping incoming messages.

I’ve deliberately kept the scope narrow. InboxNest is for one-to-one customer conversations. It doesn’t send newsletters, purchased lists, cold outreach, or marketing campaigns, and I’m not trying to turn it into an enterprise help desk.

I’d especially appreciate feedback on three things:

1. Is the choice between direct MX and forwarding understandable? 2. Is the value clear for someone managing several products or businesses? 3. What about connecting a domain to a new service would make you hesitate or decide not to continue?

c'mon

Not sure, maybe check on reddit in one of the real estate subs.

No, I had a couple of agents give it a spin. I am letting them use it for free in exchange for feedback.

I just built this yesterday, so 0. Want to be my first?

Ok, gotcha. I think this is doable. Show the excerpt from the original document so the user has confidence the data is correct.

Thank you for the feedback.

My apologies, yes this is for the American market.

Yes, I think it varies by state.

Hello HN, I’m a solo developer building tools for real estate workflows. I built OfferGridAI after watching listing agents repeatedly struggle with the same problem during hot markets.

When a property gets multiple offers, each offer usually comes in as a 10–20 page PDF. Under tight time pressure, agents have to manually dig through each document and rebuild a spreadsheet to compare things like price, net to seller, contingencies, financing, closing timeline, escalation clauses, etc. It’s not conceptually hard, but it’s stressful, time-consuming, and easy to miss details buried deep in the PDFs.

I wanted a way to make that moment less chaotic.

The idea: Upload multiple offer PDFs → extract the key terms → generate a clean, side-by-side comparison grid that’s easy to walk through with a seller.

Instead of just dumping text, the tool normalizes the information into comparable fields (price vs net, contingencies, financing strength, days to close) and adds a short summary highlighting tradeoffs (e.g. highest price vs highest certainty to close).

What it focuses on:

Structured extraction of common purchase-agreement terms

Normalizing offers so sellers can compare apples to apples

Surfacing risk factors (financing type, contingencies, timeline)

Producing a seller-ready grid rather than raw AI output

What it intentionally does not do:

Make decisions for agents or sellers

Replace professional judgment

Integrate with MLS or transaction management systems (at least for now)

The goal is to be a fast decision-support tool for a very specific, high-pressure moment.

I’m early and still refining the scope, especially around:

Which fields matter most in practice

How to communicate “risk” without over-claiming

How tolerant users are of “best effort” extraction vs perfection

I’d love feedback from anyone who’s worked with complex PDFs, document comparison, or decision-support tools under time pressure, or from anyone who’s built vertical SaaS in heavily regulated industries.

Happy to answer questions and learn from the community.

I respectfully disagree. Your LinkedIn job history should match what your resume says (generally speaking).

This is a recruiter-facing tool that compares a candidate’s resume with their LinkedIn profile PDF (uploaded by the recruiter) and flags mismatches in job titles, dates, roles, skills, and timelines.

I would love some feedback.

I don't think you can find older kids channels in YouTube kids.