IntroJoy reaches 10,000 users in 6 months

The situation

Making a warm professional introduction involves more coordination than it should. The connector emails person A to ask if they want to be connected, waits for a reply, emails person B for the same, waits again, then writes the mutual introduction email, only to be copied on the back-and-forth that follows while hoping neither party feels their inbox was disrupted without permission.

The problem is consent and coordination happening manually when both could be handled by a structured tool. IntroJoy is that tool. We built it as a web app where the connector drafts the introduction once, both parties receive an opt-in confirmation email, and the connection is made only when both agree. The client reported that 10,000 users joined in the first six months, and active users expanded their professional networks by 20%.

The asymmetry is the point: an email that takes the connector 30 seconds to write commits someone else's time. Mary is supposed to get coffee with Jack because Joe thought it would be a good idea. And if Mary ignores the intro, she looks like a jerk. Skipping consent is the fastest way to burn social capital. IntroJoy makes the 30-second ask stop committing someone else's afternoon.

What we had to solve

• Building a double opt-in flow that felt like a warm introduction, not a compliance form

  The entire value of a warm introduction is that it carries the connector's credibility and feels personal. An automated flow that reads like a system email undermines that credibility immediately. The design challenge was making the confirmation email feel like it came from a person (using the connector's own name, their drafted introduction text, and the context they provided) while the underlying workflow was fully automated. Getting that balance right between automation and apparent personalization was the UX and copywriting challenge at the core of the product.

• Managing the state machine for introductions reliably across multiple email clients

  An introduction can be in a dozen states: draft, sent to party A, party A accepted, sent to party B, both accepted, declined by either party, expired after no response, re-sent after reminder. Each state transition was triggered by email confirmation links that needed to work across Gmail, Outlook, and other clients without link-click tracking failures. Building a state machine that handled retries, reminder scheduling, expiry logic, and edge cases (one party accepts before the other has opened the email, a confirmation link clicked twice) was the backend engineering challenge.

1. Neither party gets connected without explicitly saying yes

   Each party receives an independent opt-in email carrying the connector's introduction text. Neither party sees the other's contact details until both have accepted. Declining or not responding within the expiry window closes the introduction without either party being connected without consent. The confirmation links work across Gmail, Outlook, and other clients without requiring recipients to create an account.

   

2. Connector's work ends at submission: the platform handles everything after

   Connectors enter the two parties' details, draft the introduction text, and submit. The platform handles everything from that point: sending confirmation emails to each party, monitoring responses, triggering the mutual introduction when both accept, and sending reminders if a party has not responded after a set period. The connector's involvement ends at submission.

   

3. Tone stays personal, structure stays consistent every time

   Connectors work from pre-built templates that carry their name, the introduction context, and the call to action. Templates are editable before sending so the tone stays personal, but the structure is consistent. The preview view shows exactly what each party will receive before the introduction is sent.

   

4. Connectors see every outcome without following up manually

   Every introduction is visible from the dashboard with its current state: pending acceptance from party A or B, both accepted, declined, or expired. Connectors see the outcome of every introduction they have made without manually following up or tracking anything in a spreadsheet. Completed introductions include the timestamp each party accepted.

   

How it runs

React

The introduction dashboard shows multiple active introductions simultaneously, each at a different state. React's component model gave us the interactive, real-time status view those concurrent states required without a page reload per introduction.

Node.js

The backend handles email dispatch, opt-in confirmation webhook processing, state machine transitions, reminder scheduling, and expiry logic, all concurrently. Node's event-driven model managed those async workflows without thread management overhead.

PostgreSQL

Introductions follow a defined lifecycle with distinct states and timestamps for each transition. A relational model captured that history with the transactional integrity needed to prevent duplicate state updates when a confirmation link was clicked more than once.

AWS

An introduction platform where confirmation emails land in spam fails by definition. AWS SES provided high-deliverability email dispatch with SPF and DKIM configuration. Lambda ran the reminder and expiry workflows on schedule without dedicated server infrastructure to maintain.