Web2026
Fazawwijuhu
A supervised platform for lawful marriage introductions.
- Live
Project factsبيانات المشروع
In short
A platform that introduces people seeking marriage under explicit, published conditions with administrative supervision throughout, deliberately structured to keep the process within religious bounds rather than reproducing a dating app.
The compartments
- Role
- Solo
- Year
- 2026
- Status
- Live
Built with
- Next.js 16
- React 19
- TypeScript
- Convex
- Better Auth
- Tailwind v4
- shadcn
- Base UI
Where to find it
What it isما هو
The default shape of this product is a dating app, and the default shape is exactly what the users this is for want to avoid. The design problem was structural rather than visual: what does the flow look like when open browsing and private messaging are the things you are trying to prevent?
The answer was a form-driven, admin-supervised pipeline. Applicants answer a structured questionnaire that differs by gender, agree to explicit published conditions, and every introduction passes through administrative review rather than happening directly between two users.
Built on Convex with Better Auth, where the server holds the rules and the client is only a view of them.
الشكل الافتراضي لهذا المنتج تطبيق مواعدة، والشكل الافتراضي هو بالضبط ما يريد مستخدموه تجنّبه. فكانت مشكلة التصميم بنيوية لا بصرية: كيف يبدو المسار حين يكون التصفح المفتوح والمراسلة الخاصة هما ما تحاول منعه؟
كان الجواب مسارًا قائمًا على استمارات وبإشراف إداري. يجيب المتقدمون عن استبيان منظّم يختلف بحسب الجنس، ويوافقون على شروط معلنة صريحة، وتمرّ كل تعريفة عبر مراجعة إدارية بدل أن تقع مباشرة بين طرفين.
بُنيت على Convex مع Better Auth، حيث تُحفظ القواعد على الخادم ولا يكون العميل إلا عرضًا لها.
Results
- Server-enforced visibility rules. The client cannot request what it may not see.
- Questions and religious copy editable by the product owner without a deploy.
- Publication gated behind recorded consent plus admin approval.
- قواعد ظهور مفروضة على الخادم. لا يستطيع العميل طلب ما لا يحق له رؤيته.
- أسئلة ونصوص شرعية قابلة للتحرير من صاحب المنتج دون نشر.
- النشر محكوم بموافقة موثّقة واعتماد إداري.
Challenges
Each one opens twice: what went wrong on the left, what I did on the right.
01
The rules are the product, so they cannot live in the UI
Problem
If eligibility and visibility rules are enforced by which screens the client renders, anyone who inspects the network can step around them. For this product that is not a bug class, it is a breach of the entire premise.
What I did
Convex functions are the source of truth and the enforcement point. The client cannot request what it is not entitled to see, regardless of what it renders.
02
The questions must change without a deploy
Problem
The form questions and the published conditions are religious and editorial content, not engineering decisions. Having them hard-coded means the person who owns that content has to go through me to change a sentence.
What I did
Questions and Arabic copy live in dedicated, owner-editable config modules, separate from application code and marked as such in the repo layout.
03
Publishing someone's details is irreversible
Problem
An accidental disclosure here is not a UI bug. It affects a real person's reputation and family, and it cannot be undone by deleting a record afterwards.
What I did
Nothing is visible by default. Publication requires explicit, recorded consent from the applicant plus administrative approval, so disclosure needs two deliberate acts rather than one missing check.
Keep goingتابع
Next project
Al-Tibyan Educational CenterQuran memorisation circles, run properly on a phone.Open it →افتحه ←Shelf
All projectsAll 40, in six compartments.