YASAD Connect: An Invite-Only B2B Matchmaking Platform for an Industry Association

Client

YASAD, the Software Industrialists Association, is the professional body representing Turkey's software sector. Its members are software companies: enterprise software houses, SaaS ventures, system integrators and consultancies.

Internative is a YASAD member and serves on the association's audit board. We came into this project as both a member and the developer. We did not have to hear the problem secondhand, because we were living it too.

Challenge

An association puts its members under one roof. That does not mean they know each other.

Networking depended on events. A conversation in a corridor at a summit, a business card, and then nothing. When the event ended, so did the connection. An event agenda tells you the session time, not the person who should be sitting across from you.

Nobody knew who sold what, or who needed what. A member looking for a channel partner in the Gulf and another member with two partners already in that market could sit in the same association and never find each other. What blocked the match was not distance, it was visibility.

A public directory was not the answer. A company's commercial need is not public information. "We have a gap on the payments side" is a business opportunity and an admission of weakness at the same time. Who sees it matters as much as what it says.

Access had to stay with the association. An app anyone can sign up for is not a closed member network. Members using several work email addresses made it harder still: someone invited at a corporate address gets turned away when they try their personal one.

What makes a B2B matchmaking app hard to build

Three things separate this product type from an ordinary social network. All three are architectural decisions rather than features bolted on later.

The scope boundary has to be real. In a closed network, hiding a list in the interface is not enough. The server should never send that data at all. A hidden list is a list anyone watching network traffic can read.

The permission sequence must hold. Discovery, connection and messaging are separate steps. Nobody should end up inside a conversation they did not agree to. Loosen that order and the product becomes an unsolicited message channel within weeks, and members stop opening it.

Profile data makes a match meaningful, not the algorithm. What you offer, what you are looking for, which sector, which city. If those fields go unfilled, no matching engine will save the product. The real design work sits in the profile form rather than the recommendation model: short enough that people think it is worth completing, detailed enough to make a match possible.

Solution

We built the mobile app, the admin panel and the landing site end to end. The whole product is one loop: you are invited, you find the right person in your group, you connect, you write, and you meet.

Invitation and matchmaking group

There is no sign-up form. The association adds an email address to the invited list of a matchmaking group and sends the invitation. A matchmaking group is a closed circle: a summit, a programme, a partnership network.

A user can link several work addresses to one account, and each address brings its own invitations. An email address belongs to exactly one account. An address already registered elsewhere is never silently absorbed; it returns a clear error.

Passwordless login

There is no password, so there is nothing to forget. The user types an email address and a six-digit code arrives.

The security sits in the rules around that code. It is valid for ten minutes, a new one requires a sixty-second wait, and each code allows five wrong attempts. Thirty failed attempts from the same network within ten minutes put that network on a fifteen-minute hold, and a single successful login resets the counter. The threshold stops a brute-force attempt without punishing a room full of people signing in from the same office at once.

The result: there is no password reset screen in the app, because there is no such flow.

Discovery

A user filters the people and companies in their group by the service they offer, the solution they are looking for, their sector and their city.

A company profile carries its products as well as its description: the product name, its sector and how it is delivered (SaaS, PaaS, on-premise). The answer to a buying question is usually in the product list rather than the company's summary line.

Connection and messaging

Messaging stays closed until a connection request is accepted. Once it is, the chat opens and the header shows which matchmaking group the conversation came from. That is the product's single access rule, and it never leaves the screen.

The conversation stays inside the app. Email addresses and phone numbers are not handed over automatically. A user can mute a conversation, archive it, block a member, and report behaviour to the association.

Meeting scheduling

A meeting request proposes the day, the time, the place, and whether it will be in person or online. Place and link are separate fields. When the other side accepts, the meeting lands on both lists.

Upcoming meetings collect in one list with the next one on top. Requests waiting for a reply are marked in their own colour, and an accepted meeting can be written to the phone's calendar.

Group scope enforced on the server

Discovery, messaging and meeting queries are all constrained on the server by the user's group memberships. It is not a list hidden on screen, it is a list the server never sends.

Someone who does not share a matchmaking group with you cannot see your profile, and cannot send you a connection request or a message. This is the platform's single access rule and the promise its published privacy documents make.

Admin panel

The association manages invited lists, matchmaking groups and FAQ records from the panel. The FAQ text read inside the app is the record published in the panel. There is no second copy kept somewhere else, waiting to be updated.

Privacy and data control

Notifications are switched on and off one at a time: connection requests, messages and meeting reminders are each handled separately.

The way out is in the app as well. A user deletes their own account and the deletion is scheduled thirty days ahead. Through that window they are invisible to everyone, nothing of theirs is destroyed, and they can change their mind at any point. KVKK and GDPR requirements were built as part of the architecture rather than added as a layer afterwards.

Landing site

connect.yasad.org.tr was built in both languages. How the app works, the features, the group scope, the FAQ, the store links and the legal texts are gathered in one place.

Result

The project started in May 2026 and was delivered at the end of August 2026. Three products shipped: the iOS and Android mobile app, the admin panel the association runs, and the landing site.

The app went live on the App Store on 26 August 2026. Version 1.0.0 supports iOS 15 and above, and it is on Google Play as well. The interface runs in Turkish and English.

Technology

Next.js · NestJS · Fastify · Flutter · Socket.IO · BullMQ · pnpm · Turborepo · Turbopack · monorepo · shadcn/ui · Zustand

Building a closed member network?

If you run an association, a chamber, a union or a programme, let us define the scope together. Start with the question of who can see whom; the rest of the product is built on top of that answer.