Start with the operational relationships
Attendance, fees, staff, exams and communication are often treated as separate screens. The product direction is to connect these functions around the school, its roles and its academic calendar. A change in one workflow can affect other users, which makes permissions and data relationships central design questions.
Published product scope
The existing AogsiERP introduction describes student and staff management, attendance, fee management, exams, homework, circulars, timetables and academic reporting. The product is still evolving; the introduction describes its scope rather than a completed release checklist.
Technical direction
AOGSI's published project record lists React and TypeScript, NestJS, PostgreSQL and Prisma, with Redis, BullMQ, Docker and AWS S3 among the associated technologies. Scheduling-related work lists OR-Tools and FastAPI.
The design questions behind those choices include keeping school data separated, enforcing role-specific actions, handling background work and representing scheduling constraints. Those questions should be tested against explicit acceptance criteria as the product evolves.
Scheduling is an ongoing development area
The product introduction describes timetable generation, faculty workload balancing, lab-aware scheduling and substitution support as work being developed. These remain clearly separated from demonstrated released capabilities.
A useful next validation step is a documented test dataset, a list of hard and soft constraints, and repeatable results showing where the scheduler succeeds or needs a human decision. No scheduling benchmark or customer impact figure is claimed here.