Dev.to WebDev 🛠 Dev 👁 0 📖 4 min read

Building SupportMeet: Matching by Lived Experience, Private by Default. What Worked, What Broke

Money trouble has a timing problem before it has a maths problem. Rent lands on one date, utilities on another, and a reduced shift or a car repair lands in between. The bills do not wait for the paycheck, and the gap be

Money trouble has a timing problem before it has a maths problem. Rent lands on one date, utilities on another, and a reduced shift or a car repair lands in between. The bills do not wait for the paycheck, and the gap between the two is where the stress actually lives.

Building a peer support product for that moment raised a design question that general advice sites never have to answer: how do you match someone with people who have lived the same squeeze, without asking them to publish the most private details of their life to do it?

The problem with generic support spaces

A large open forum sorts by topic, and topic is too blunt an instrument here. Two people can both be worried about money and have almost nothing useful to say to each other. One is facing a late rent notice for the first time. The other has been through three winters of utility arrears and knows which phone call to make first, which paperwork to keep close, and how to pace decisions when everything feels urgent at once.

The useful unit is not the topic. It is the lived experience behind it: the kind of stress, the stage it has reached, and the country it is happening in, because programmes, deadlines, and protections differ by place.

What was built instead

Three choices shaped the build:

1. Match on lived experience, in small circles. Instead of one large feed, a person shares what they are going through and is matched with a small circle of people who have lived the same kind of thing. Small matters. A circle can hold context across days, notice when someone goes quiet, and answer from memory rather than from a script.

2. Private by default, at the data level. Privacy could not be a toggle buried in settings, because the people most likely to need support are the least likely to go looking for a toggle. Posts start private to the circle. Sharing wider is a deliberate step a person takes later, not the starting state they have to undo. That single default changed what people were willing to write in their first post.

3. Conversation sits next to practical help. A supportive reply helps someone get through tonight. It does not fill in the form. Circles sit alongside pointers to practical help and to professionals and programmes nearby, so a conversation can end with a concrete next step as well as company: a phone call worth having early, a local programme, a form to start in the morning with a clearer head.

That combination is the whole product behind SupportMeet, a free peer support site where people share what they are going through and are matched with circles who have lived the same thing.

What worked

Treating the match as the product worked. Early testing kept returning the same feedback: the relief was not hearing general encouragement, it was hearing a detail that only experience teaches, from someone who recognised the situation without needing it explained or justified.

The private default worked too, in a measurable way that had nothing to do with metrics dashboards. First posts got longer and more specific once people understood the audience was a small circle and not the open internet. Specific posts get specific answers. Vague posts, written defensively for a public feed, mostly get sympathy.

Keeping practical help in the same view as the conversation also held up. Advice that arrives with a nearby programme attached is advice someone can act on the same week.

What broke, or nearly did

The first matching categories were too broad. A single bucket for money stress matched people whose situations shared a word and nothing else, and weak matches are worse than a short wait, because a weak match teaches a new member that the circle does not really understand. The categories had to be split by the shape of the problem, not just its subject, even though narrower categories mean smaller pools and slower first matches.

The second failure was the empty circle problem. A person who posts at 2am in a less common situation may wait for a match, and a waiting screen that says nothing is its own kind of verdict. The waiting state had to explain what was happening, offer the practical help view in the meantime, and never pretend a match existed when it did not.

The third was tone in the interface itself. Cheerful empty states and upbeat prompts landed badly next to a post about a late notice. The language that survived was plain and steady: say what the state is, say what happens next, and do not perform optimism the product has not earned.

Lessons for builders

Match on experience, not just topic, when the value of a reply depends on having been there.

Make the safe state the default state. If privacy depends on a setting, most people will experience the product without it.

Put the human support and the practical next step in the same place. People in a hard season do not have spare energy for switching between a community in one app and a directory in another.

Discussion welcome: for anyone building matching or community products, how did you handle the trade between narrow, accurate matches and fast first matches?

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.