Web2026
Fazawwijuhu
A supervised platform for lawful marriage introductions.
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.
- Production
- Fazawwijuhu
- Role
- Solo
- Year
- 2026
- Status
- Live
- Format
- Web
- Built with
- Next.js 16React 19TypeScriptConvexBetter AuthTailwind v4shadcnBase UI
- Where to find it
- Visit the siteSource
Treatment
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، حيث تُحفظ القواعد على الخادم ولا يكون العميل إلا عرضًا لها.
Challenges
The rules are the product, so they cannot live in the UI
The 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.
The questions must change without a deploy
The 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.
Publishing someone's details is irreversible
The 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.
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.النشر محكوم بموافقة موثّقة واعتماد إداري.