En-Nur

A community funded month by month

En-Nur is a mosque community in Switzerland. Its members, people of every age who live in the community, pay a monthly membership fee and also give donations, and the community depends on both to operate. Membership is not a one-off sign-up but an ongoing relationship, which means the system behind it is used constantly rather than occasionally.

I designed and built that system in 2025.

Off-the-shelf software built for someone else's workflow

The community managed memberships and donations through third-party software. It was expensive and inflexible, but the core issue was that it had never been built for a mosque. Generic membership tools are designed around the average association, so they arrive with their own assumptions about how members register, how fees are collected and how money is reported. The community's actual requirements had to be squeezed into fields and processes designed for someone else, and the ones that didn't fit simply weren't supported.

The result was a tool the people running the community spent their time working around rather than with. Work the software should have done still happened by hand, and every month they paid a subscription for a system that didn't match how they operate.

They needed a system built around their own requirements, at a cost that made sense for a community organisation, and one they would own rather than rent.

Starting from the business logic, not the screens

Discovery meant working through, with the people who run the community, the questions any system has to answer before it can be designed. Who can become a member and how they register. When a monthly payment falls due and what happens if it's missed. How donations differ from membership fees and how each needs to be recorded. What the admins need to see at the end of every month.

Those answers became the brief, and anything that didn't serve them didn't get built.

Every age, one system

The platform serves two kinds of users with very different jobs.

Admins run the community's side of things. They need to see every member, know at a glance who has paid and who hasn't, follow up on what's missing, and report on donations. Their work is detailed and recurring, and the system has to carry as much of it as possible.

Members need very little from the system, but they need it to be effortless. They register themselves, log in, pay their monthly fee, see their payment history and check their status. And because members are everyone who lives in the community, of every age, the same member dashboard has to work just as well for a student as for a grandparent. That set the rule for the member side: it does only what a member needs, and nothing else.

Mapping the flow before the interface

The system flow came first. A person registers and a member record is created. The monthly payment cycle begins. When a payment falls due, a reminder goes out. When the payment arrives, it's recorded and the member's status updates. Donations run as their own flow alongside, and both feed into the reporting that admins rely on.

Designing the flow before the interface meant the admin and member dashboards are two windows onto the same logic and the same data, rather than two separate tools that have to be kept in agreement. When a member pays, the admin sees it immediately, because there is only one record to change.

Two dashboards built for two different jobs

The admin dashboard carries the complexity. Members, payments, donations and reporting all live here, because this is where the work of running the community happens. Payment status is visible across the whole membership, so the question of who is up to date has an immediate answer.

The member dashboard stays simple. Three things: your details, your payments, your status. A member can update their information and see exactly where they stand without having to ask anyone, which also spares the admins a whole category of questions.

Reminders are automated. When a payment falls due, the system sends the reminder itself. Admins no longer have to work out each month who needs one.

Donations are kept separate from membership fees. They are different kinds of money with different meanings, so they are recorded separately and reported separately. Admins get clear donation reporting without having to untangle it from membership payments first.

Clarity for members, density for admins

The member side turns the every-age rule into three concrete choices: plain language rather than technical terms, obvious actions with nothing hidden behind menus, and a clear hierarchy in which the one thing a member cares about most, whether they are up to date, is visible the moment they log in.

The admin side carries more density, because it is used regularly by the same few people who know it well. It follows the principle of progressive disclosure, the answer first and the detail on demand, so a full view of the membership never becomes a wall of data.

Both sides were designed in Figma and refined through rounds of feedback with the client, each screen tested against the system flow before moving on.

A custom Laravel application

The platform is a custom application built on Laravel. Registration and login run on Laravel's authentication, member and payment data lives in a MySQL database accessed through Eloquent ORM, and the interfaces are rendered with Blade. A relational database suits this system naturally, since members, payments and donations are records that belong to one another.

Payments are processed through Stripe, so members can pay their monthly fee and give donations online, and card details are handled by Stripe rather than stored on the platform. Each successful payment is recorded against the member and updates their status automatically.

The date logic behind the monthly billing cycle and due-date calculations is handled with Carbon. Reminders run as scheduled jobs and are delivered by email through PHPMailer, so the follow-up work happens without anyone triggering it. The application is deployed on Render, which keeps hosting simple and costs predictable for a community organisation.

A system the community owns

No more monthly subscription for software that never fit. Memberships, payments and donations now run on a platform the community owns outright, and the routine work of each month happens on its own.

Ownership also changes what happens next. When the community needs something new, it becomes a feature to build, not a limitation to work around.