‹ Institution Management System with Drag and Drop Builder CMS for Schools, Madrasas, Colleges, Universities and CoachingQuality report QR-26-00135
Institution Management System with Drag and Drop Builder CMS for Schools, Madrasas, Colleges, Universities and Coaching
Multi-tenant & Multilingual institution management SaaS with auto-generated websites for schools, madrasas & university.
- Product ID
- B0097-78452
- Builder
- MD FAHIM
- Version reviewed
- 1.0.0 · released 13 Nov 2026
- Stack
- Next.js 16.4 (App Router, Server Actions) with React 19.2 · TypeScript 5.9 on Node.js 22.12+ · PostgreSQL 16+ (Neon or self-hosted) via Drizzle ORM 0.45
- Built with
- Claude Code, Google Antigravity
- Review period
- 9 Nov 2026 – 13 Nov 2026 · 1 round of changes
- ✓AI code audit6 checks · 9 Nov 2026
- ✓Installed & run13 Nov 2026
- ✓Demo vs delivered13 Nov 2026
- ✓Final sign-off13 Nov 2026
At a glance
- ✓Installed and run from the delivered code — 8 of 8 checks answered yes.
- ✓Live demo compared with the delivered code — 7 of 7 checks answered yes.
- !12 of 15 promised items delivered (setup guide, example config and the rest).
- ✓Security scored 77/100 with no failing check.
- !4 open warnings — explained in part 1.
AI code audit
The full source archive was read by our AI auditor against each check. It reads the code — it does not run it; running it is part 2.
| Check | What we found | Score | Result |
|---|---|---|---|
| Secrets & credentials | No live API keys, private keys or connection strings with real credentials were found in the digest. The weak points are a published default seed password (Shikkha@2026) used for every demo account, and a hardcoded development fallback for the session signing secret in a project file. Both need hardening so a buyer cannot deploy with a guessable password or a known JWT secret. | 82 | Warning |
| Dependency vulnerabilities | The project has one manifest (package.json) and a package-lock.json (119 KB), with every dependency pinned to an exact version and no wildcard or latest tags. I could not confirm any known critical vulnerability. Some hygiene issues remain: build tooling in production dependencies, an unusual tooling package, and versions I cannot verify against advisories. | 80 | Pass |
| Authorisation & access control | The visible design is sound: signed JWT sessions re-checked against a DB row, RBAC bitmasks, an edge gate on protected segments, and scrypt password hashing. However, the excerpts omit most server actions and the API routes (/api/me, /api/media/[id]), so ownership checks cannot be confirmed. Some demo and bootstrap features also carry production risk if misconfigured. | 72 | Warning |
| Database access rules | The visible code uses Drizzle's parameterized builders, and the sessions, audit and membership queries show no string-built SQL or unscoped deletes. However, the schema files, most server actions and the generic module CRUD layer were not provided, so tenant scoping and index coverage could not be verified. Several tenancy and secret-handling risks remain. | 78 | Warning |
| Code structure & duplication | The project separates server actions, lib, db schema and UI components into distinct folders, and CLAUDE.md documents the layering. The main maintainability costs are a very large seed file and hard-coded demo credentials and session secrets scattered through code and docs rather than centralised configuration. | 84 | Pass |
| Build reproducibility | Pinned deps, a lockfile, a multi-stage Dockerfile and a compose file with DB init are present, which gives a solid base. However, several gaps could break a clean-machine build or start: a stray neon.ts using an unusual dev dependency, an entrypoint and setup doc that could not be fully verified, and a very large seed file loaded at DB init. | 72 | Warning |
Open warnings
Problems that did not stop the listing. They stay on the product page until a later version fixes them.
No live API keys, private keys or connection strings with real credentials were found in the digest. The weak points are a published default seed password (Shikkha@2026) used for every demo account, and a hardcoded development fallback for the session signing secret in a project file. Both need hardening so a buyer cannot deploy with a guessable password or a known JWT secret.
The visible design is sound: signed JWT sessions re-checked against a DB row, RBAC bitmasks, an edge gate on protected segments, and scrypt password hashing. However, the excerpts omit most server actions and the API routes (/api/me, /api/media/[id]), so ownership checks cannot be confirmed. Some demo and bootstrap features also carry production risk if misconfigured.
The visible code uses Drizzle's parameterized builders, and the sessions, audit and membership queries show no string-built SQL or unscoped deletes. However, the schema files, most server actions and the generic module CRUD layer were not provided, so tenant scoping and index coverage could not be verified. Several tenancy and secret-handling risks remain.
Pinned deps, a lockfile, a multi-stage Dockerfile and a compose file with DB init are present, which gives a solid base. However, several gaps could break a clean-machine build or start: a stray neon.ts using an unusual dev dependency, an entrypoint and setup doc that could not be fully verified, and a very large seed file loaded at DB init.
Requirement list
What the builder agreed to deliver before uploading — 12 of 15 met.
- Complete source for every component Met
- No real credentials in the archive Met
- Builds from a clean machine Met
- Database script or migrations Met
- Authentication and roles on every mutating endpoint Partial
- Pinned dependencies without critical CVEs (nice)Partial
- Documentation set (nice)Met
- Working live demo Partial
- README.md Met
- HowToSetup.md Met
- CLAUDE.md (or AGENTS.md) (nice)Met
- CHANGELOG.md (nice)Met
- .env.example Met
- a project file Met
- a project file (nice)Met
Human review
Reviewers from the Vibe96 team in Dubai worked through each question below; a final reviewer signed it off.
Stage 1 — Installed and run from the delivered code
Completed 13 Nov 2026A reviewer installed the product on a clean machine, following only the guide that ships with it.
| Question | Answer | Reviewer's note |
|---|---|---|
| Packages restored without errors | Yes | |
| Solution builds clean | Yes | |
| Database created from the shipped script or migrations | Yes | |
| First sign-in works with the documented steps | Yes | |
| Setup guide is accurate and complete | Yes | |
| Every module in the feature list opens and works | Yes | |
| No real secrets in the archive | Yes | |
| Branding and company details can be changed without code | Yes |
Stage 2 — Live demo compared with the delivered code
Completed 13 Nov 2026A second reviewer checked that what the listing and demo show is what the buyer receives.
| Question | Answer | Reviewer's note |
|---|---|---|
| Demo URL is reachable | Yes | |
| Demo credentials work | Yes | |
| Demo runs the same version as the archive | Yes | |
| All five differentiators are visible in the demo | Yes | |
| Screenshots match the demo | Yes | |
| Nothing in the demo is missing from the code | Yes | |
| Datasheet claims are accurate | Yes |
Changes asked for during review
- None — approved on the first round.
- Sign-off: approved for sale on 13 Nov 2026 with 4 warnings shown publicly.
What this report covers — and what it doesn't
- It covers version 1.0.0 exactly as the buyer downloads it: the source archive, the setup guide and the live demo on the dates above.
- It is not a penetration test, a performance or load test, or a legal review of third-party package licences.
- Scores are a point in time. Libraries age; a later version is audited again and gets its own report.
- Your setup matters. Hosting, configuration and changes made after purchase are outside this review.
- How the score is made: each AI check is scored 0–100 and weighted (security counts most). A listing needs 75 or more, no failing check, and the human review passed.
- Always try the live demo before buying, and ask the builder questions from the product page.
Vibe96 FZ-LLC, Dubai, UAE. This report describes the product at the time of review and is not a warranty.