Mufeed

We separated the rules for money and exams from everything else.

The payment and exam rules live in a separate core and are tested without a live database. The database decides the price and the state of an order, and the site carries out what the rules decided.

1. 01

   Build the learning journey around one practitioner's sequence rather than an unstructured content library.

2. 02

   Keep enrolment, accounts, study progress, and assessment in one platform.

We closed the places where a payment, a price or a certificate could quietly break.

The learning, assessment, payment and publishing systems share one domain model, while money and exam rules stay isolated from the network and database layers.

Application

Next.js, React and strict TypeScript

Data

Supabase PostgreSQL, private storage and row-level access policies

Delivery

Public pages with protected student and administration systems

• Business rules live in a pure core

  Payment and examination logic can be tested without a live database. It returns explicit effects for the application to execute instead of hiding side effects inside the rules.

• Payment is designed against duplication

  The database remains authoritative for price and order state, while compare-and-swap updates and uniqueness constraints protect retries from charging twice.

• Content is treated as untrusted input

  Uploads are checked by their bytes, images are decoded and rebuilt, course files remain private, and author text is rendered as structured elements rather than injected HTML.

• The release gate checks the whole system

  The automated gate covers migrations, security, payments, examinations, progress, multilingual content, certificates and the production build before release.

1. 01

   The database belongs to a partner

   The production database belongs to a partner, and the team does not connect to it. Changes go out as files, and the partner applies them. Every change that touches money first runs on a temporary database, where a check deliberately tries to break the rules that protect money. A separate test makes sure no check drops out of the chain; it found two that had never run.

   The data stays with the partner, and the changes are still checked.

2. 02

   No exchange rate, on purpose

   The owner sets the price of each course, in one currency. Since 23 August 2026 there has been no exchange rate in the payment code, and a test stops a release if one appears there again.

   On the site, a buyer pays the price the owner set, not the result of the day’s conversion.

3. 03

   The student types the name

   Students type the name for their certificate themselves, and one invisible character in it reverses all the text after it. Before, such characters were removed only in the administrator’s preview, not in the document every graduate receives. Now they are removed before the name reaches the certificate and the file name.

   A graduate’s certificate reads the way the platform issued it.

4. 04

   One tap, one order

   Telegram delivers the same tap again if the server has not answered within a few seconds, and a slow first start of the server is enough for that. Without protection, the “I have paid” tap would create a second order. Tests do not show it, because there the server is already running and always answers in time. Now a repeated delivery of the same tap is dropped, separately for each of the two bots.

   A slow server answer does not turn into a second order.

5. 05

   Prices for AI, from the checkout

   The site publishes an llms.txt file with its courses and prices for AI tools. It used to be written by hand and named old prices and pages that had moved. Now it is built from the same price table the payment runs on.

   If an AI tool reads the file, it gets the prices the checkout charges.

69 database migrations · 83 pages · 106 automated test files. Counted by us from the repository’s files on 26 September 2026.