Naseeb

tl;dr: an algorithmically-driven matchmaking platform designed to run autonomously.

The accelerating digitalization of modern society continues to foster social atomization and the decline of traditional communities. This shift affects many aspects of life, including the challenge of finding a lifelong partner. Historically, communities served as the bedrock for establishing pre-vetted, authentic, and deep connections within a shared social fabric, a method widely regarded as optimal within these cultures. But for many, that tight-knit group of like-minded people simply isn’t available and is often replaced by fast-paced applications driven by superficial features. The community’s needs provided the blueprint for a better solution. With the necessary vision in place, LLMs were available to teach us a thing or two about web development. The result is Naseeb, a unique, algorithm-driven matchmaking B2C SaaS currently serving hundreds of active profiles and consistently delivering weekly matches.

A new reality

Most people meet online nowadays. This statistic is from the US, but the trend here is similar. Meeting online has become easy and low-barrier, but does that make it better than directly meeting face-to-face? I honestly don’t know. What I do know is that we’re already heading in this direction, and fast.

The community needs a better solution. Right now, Muslim organizations and volunteers collect profiles and facilitate matches out of pure goodwill, often for free. But these matchmakers quickly hit a wall. As more people join, finding the right match becomes exponentially harder. The workload becomes unsustainable, forcing them to cut corners and sacrifice quality just to keep going.

They’re also constrained by what matters most to the community, which is quality service, Islamic principles, and especially privacy. Different services handle this in different ways. Some have open databases, some require approval, others keep things private but share select profiles on social media for marketing (and are sometimes paid profile boosts). Our market research showed us where these services sit in the landscape, and where we want Naseeb to be positioned. The challenge is maximizing both expectations in privacy and quality of service, i.e. getting people matched quickly without having their data open on the internet.

A closer look at the problem

To illustrate the rapid growth, consider the total manual workload based on three cumulative factors using an idealized scenario with $N$ profiles and $k$ essential requirements. We assume a single profile check takes a minute per criteria $k$. The filtering time

$$T_\text{filter}=\frac{N(N-1)}{2} \cdot 0.016\cdot k$$

represents the time in hours required for the initial check for all unique pairs. We assume that a fraction $P$ of total pairs survive the initial filter. The sorting overhead comes from the matchmaker attempt to find the best possible matches by sorting them according to a manually derived score. We assume that scoring these survivors requires 50% of the effort of the filtering process itself. Finally, let’s not forget to incorporate 15-minute coffee breaks every $H$ hours of work. We can define the total time it takes as

$$T_{\text{total}}=T_\text{filter}\times \left(1 + 0.5P \right) + \left\lfloor\frac{T_\text{filter}\times \left(1 + 0.5P \right) }{H}\right\rfloor\times 0.25 \text{ h}$$

Seeing our calculation tool below, it quickly becomes clear how this good intention can turn into a catastrophe with even a modest user base (Naseeb has over 500 profiles!). Moreover, our analysis uses an idealized case, assuming perfectly standardized forms and clear dealbreaker criteria. The reality is far worse, where profiles vary wildly, sometimes depending on what the individual decides to free-type, and in the best cases, utilizing a rudimentary tool like a Google Forms or a plain WhatsApp message. This extreme lack of standardization only amplifies the human workload.

To the drawing board!

We spent a lot of time designing the optimal profile structure. The goal was keeping the form as short as possible while capturing the essential compatibility factors like height, age, languages, and origins. At the same time, profiles needed enough depth and standardization to give a representative picture of each person. Once we were satisfied with the forms, we moved on to the matching algorithm and tested it with mock data until we had something solid enough for an MVP. The algorithm itself is straightforward, though we keep the exact logic confidential. Every Friday it runs for a few seconds and generates matches for approximately half of our userbase.

We initially started with Pandas for our algorithm, but Polars proved significantly faster. Given its Python foundation, Django was a natural choice for the web framework. Its batteries included philosophy, including built in protections against common issues such as SQL injection and CSRF, helped accelerate development. For the database, we chose PostgreSQL simply because I had used it before. We use Gunicorn as the WSGI interface to execute the Python code, with NGINX sitting in front as a reverse proxy. NGINX handles the heavy lifting of serving static files and SSL termination, which improves security and performance. Finally, Redis serves as an in-memory caching layer to speed up frequent lookups. The entire stack is deployed on an Ubuntu VPS.

Interconnected applications

A key requirement for us is the ability to take a step back and let the system run without my intervention. Hence, we introduced Celery for scheduled and asynchronous tasks, powering everything from nightly matching runs to notification queues. For the communication layer, I leveraged Gmail (via SMTP) for reliable transactional emails and the WhatsApp Business API for real-time notifications, ensuring high engagement with a mobile-first user base. We integrated Mollie to handle secure, recurring subscription payments due to its developer-friendly API and strong European presence.

Furthermore, we separated the core model themes into distinct apps. The landing site kept things lightweight (for example, mailing lists), and provided access to the blog and account registration. After logging in, users can activate their account by completing payment, then fill out their profile and requirements forms to participate in matchmaking rounds. Moderators approve profiles and review messages of the weekly matches created by Celery. Messages also drive match-status progression, so ongoing moderator involvement is minimized.

Growing our user base

The first week after launch was really intense, both because it was the moment of truth after more than a year of work, and because we did not want to disappoint our early adopters with avoidable bugs. Even with a small beta group of approximately 10 to 15 people, we still encountered typical early stage issues that had to be fixed quickly. Marketing was at that time, and still is, crucial. So far, the strongest response has come from paid Instagram campaigns and strategic partnerships with local organizations. We asked for feedback and advice, and they were happy to refer relevant requests to us. We also occasionally distribute flyers at busy locations.

Future outlook

Given our current growth, I expect we will scale beyond the Netherlands and Belgium. Right now, the codebase uses a very simple stack with no clear separation between frontend and backend. This works fine while I am building it alone, but once we start hiring engineers, it will need to be more modular, with well defined API endpoints. That is why I plan to separate the layers and also upgrade to a proper frontend framework. At the moment, the frontend is intentionally basic. The main limitation I have faced with the current stack is cross device compatibility, which has required a few hacky workarounds. I expect this will be addressed more cleanly with a dedicated framework. Aside from that, I have not yet run into major obstacles with the current stack.

Closing thoughts

Real connections are forming and marriages are happening through our service. This drives us to continue refining and elevating the platform. On a personal level, the biggest lesson has been discovering how addictively enjoyable it is to build something. I’ve felt this before with academic writing and experimental work, but now I’ve experienced it in software engineering too. You find yourself spending nights and weekends on something outside your day job simply because you love it.

There aren’t many things where financial incentive and intrinsic fulfillment align so naturally, so when I find something like that, I hold on to it.