The right way to evaluate madrasa software: first list your department-level workflows, then make each vendor perform those workflows live in a demo. Do not decide from brochure feature lists or large vendor comparisons — madrasa-specific work (Hifz, Kitab, boarding, donations) is usually written as “supported” in generic school software but missing in practice.

What to verify: department needs and demos, not vendor lists

A madrasa is one institution running several distinct workflows. Before evaluating, write one line per department describing who does what:

Department Daily work What the software must do
Hifz sabaq-sabqi-manzil entry, flagging weak students per-Juz/Surah records, Tajweed scoring
Kitab (Dars-e-Nizami) book progression, Salla preparation per-book tracking, annual evaluation reports
Office admission, fees, receipts, letters bKash/Nagad fees, auto receipts, export
Boarding room allocation, leave, guardian contact room-wise lists, leave records
Administration monthly reports, inspections combined AND separate per-department reports

This table is your evaluation yardstick. If a vendor cannot demo half of these workflows, eliminate them regardless of price.

A usable sample: the madrasa needs matrix

Before any demo, fill this matrix — each row is a real task, each column a vendor:

  1. Task — a real departmental workflow (from the table above).
  2. Urgency — daily / weekly / monthly / once a year.
  3. Current method — register, spreadsheet, or memory.
  4. Demo verification — the exact step you will ask the vendor to perform.

Verification rule: supply your own sample data in every test (sabaq records for 2–3 Hifz students, one partial fee payment). Vendor demo data always looks clean — real data shows the real behavior.

Software evaluation: workflow steps and limitations

  1. Bring one representative per department to the demo — the Hifz ustadh tests the Hifz module, the accountant tests fees.
  2. After each test, write the result: passed / partial / failed, and how long it took.
  3. Test export: pull data to Excel/PDF and open it — that is your exit path if you ever switch systems.
  4. Acknowledge limitations: no software covers every sharri and administrative custom by default. Ask what requires customization, and what that costs in time and money.
  5. If you ask for references, ask for named institutions — “many madrasas use it” is not verifiable.

Evaluation: questions to ask before your demo

  • Are sabaq, sabqi and manzil recorded as separate fields in the Hifz module, or one combined note?
  • Are Qawmi and Alia report formats both built in?
  • Can donations and student fees live in separate ledgers?
  • Do attendance and fee collection work without internet?
  • If we leave, what format do we get the full dataset in?

Afterwards, compare your list against madrasa operations and the madrasha management features to see which task maps to which module. Check pricing before deciding so the total cost is already clear.

Evaluation FAQ

How many vendor demos should we take?

Two or three are enough — if you use the same needs matrix in each. More demos do not improve decisions; comparing the same tasks does.

Is watching the vendor’s own demo data enough?

No. Sample data is curated. Bring 2–3 real student records and ask for both entry and reporting.

What if some questions go unanswered?

An unanswered question is an answer. A vendor hesitant on madrasa-specific work will eventually push that work back to paper.