Most peer support matching starts with a topic. Someone selects a theme, gets placed in a broad group for that theme, and is expected to find the right people inside it. That works until it does not. Two people can share the same topic and be at completely different stages of it, with different needs, different language for it, and very different ideas about what help looks like right now.
The feature that changed the design came from the other side of the conversation. People who had already come through a hard season kept arriving with something specific to offer: not advice in the abstract, but knowledge about what the middle of that season actually felt like and what helped in practical terms. Treating that lived experience as a matching signal, rather than as background biography, became the core design decision.
What the supporter role actually changes
A peer supporter is not positioned as an expert. The value is stage knowledge. What the first month tended to look like. Which routine helped when everything shifted. How questions from family were handled. What took longer to accept than expected. When someone new is matched with a person who has lived a later stage of a similar experience, the conversation starts further along, because it does not need to explain the basics of the situation first.
That also changes what gets exchanged. Instead of general encouragement, circles trade grounded detail: how a morning routine was rebuilt, how a steadier pace at home was found, what someone wishes they had known earlier. Practical help and nearby programmes sit alongside the circles, so a good conversation can lead to a concrete next step rather than ending at sympathy.
What worked
Match on stage as well as subject. Topic alone produced groups that were too broad to feel personal. Adding where someone is in the experience, early, in the middle, or further along and offering support, made matches feel relevant much faster. Stage is a small field to collect and it does a lot of work.
Frame supporters by experience, not credentials. Early copy that sounded like expertise made potential supporters hesitate. Many people do not see themselves as qualified, even when their experience is exactly what someone else needs. Framing the role as being present, listening well, and speaking honestly from lived experience lowered that barrier without lowering the quality of support.
Keep privacy as the default. People share more honestly when joining a circle does not mean broadcasting their situation. Private by default was not a settings detail. It shaped whether the supporter model worked at all, because supporters and new members both needed to trust that a sensitive conversation stayed inside the circle.
Let experience be specific. A supporter profile that names a concrete chapter, rather than a general willingness to help, matches better. Specificity helps the matching and it helps the new member recognise that this person has genuinely stood in a similar place.
What broke
The first version treated any past experience as readiness to support. That was too simple. Someone can be through the hardest part and still not be ready to sit with the same experience in someone else, at least not yet. The design needed a lighter touch here: letting supporters choose when they are available, which stages they are comfortable with, and when to pause, without that feeling like leaving.
Topic only matching also created mismatched expectations. A new member looking for practical steps in the first weeks could land with supporters focused on reflection much later in the process. Both were acting in good faith. The match itself was wrong. Adding stage fixed more of these cases than adding more topics ever did.
Vague supporter descriptions were the third problem. When experience was written too generally, the system could not tell two supporters apart and members could not either. Prompting for the chapter, the turning points, and the practical lessons produced descriptions that actually matched people.
The takeaway
Peer support is often designed from the side of the person asking for help. Designing from the supporter side as well revealed a different system: lived experience is structured data about stage, pacing, and practical knowledge, and it deserves the same careful modelling as the request itself. A hard season stops being wasted time when that knowledge can find the person who is currently in it.
The original feature on this sits on the fleet blog. The product side lives at https://supportmeet.com , where people share what they are going through and are matched with circles who have lived the same thing, alongside practical help and professionals and programmes nearby.
For teams building peer or community products: how do you model experience that is real and useful, without turning it into a credential people feel they have to prove?
