EduCore ERP

02 · Problem

A school already holds every signal it needs to spot a struggling student. Attendance is taken daily. Exam marks are recorded each term. Fee status is tracked. The problem is that these live in separate places and nobody reads them together.

• Attendance sits in a register, so a pattern of absence is only visible if someone leafs back through it.
• Marks are filed per exam, so a slide across three assessments looks like three separate results.
• Nothing connects the two, even though falling attendance usually precedes falling marks.
• By the time a student's decline is obvious, the term is often over.
• Meanwhile the same student details are re-entered across admissions, exams and fees, and drift apart.

03 · Concept

One student record, written once and referenced by every module. Admissions creates it, attendance and exams add to it, fees reference it. No module keeps a private copy, so there is nothing to reconcile.

Once the record is unified, the early-warning layer becomes possible: the signals a teacher would notice — if they had time to read every register and every mark sheet side by side — are already in one place, and can be surfaced automatically instead of waiting to be discovered.

The framing on the product itself is run your school, smarter. Not more features; the same work, with the system doing the noticing.

04 · What it covers

1. Admissions

   Enquiry through enrolment, creating the student record everything else builds on.

2. Attendance

   Daily marking, and — more usefully — the patterns that emerge from it over weeks.

3. Examinations

   Marks entry and results, held against the student rather than filed per exam.

4. Fees

   Fee status and outstanding balances, tied to the same record.

5. AI early warning

   The layer that reads attendance and academic signals together and flags students who need attention before they fall behind.

6. Roles and permissions

   Staff open the system to the view that matches their job, enforced on the server rather than hidden in the UI.

05 · Technology

• Next.js — the application framework, server-rendered.
• React — the interface, which is mostly dense data entry.
• TypeScript — types across the student, attendance, exam and fee models.
• Vercel — hosting and deployment.
• Role-based access control — permissions enforced server-side.

06 · My contribution

EduCore is my own product — the concept, the data model, the module boundaries, the permission system, the interface and the deployment.

The part that took the most thought was scope. An ERP invites endless additions, and every institution asks for one more field. Deciding what belongs in the core product versus what is per-institution configuration is what kept it finishable.

07 · Screenshots

08 · Status

Live at educore.it.com, behind a sign-in, and in active development. Access is by account rather than public sign-up.

09 · Links

The application requires an account, so the link opens the sign-in screen. Ask me for a demo if you would like to see inside.