The original description
« I run a small music school: piano, guitar, voice. Students enrol in a weekly lesson with a teacher and a time slot. At each session I record who attended; an absence can be made up within the term. Families pay per term. I want this week's attendance, pending make-ups and late payments. »
The plan validated before generation
From that description, Blueprint Maker proposes a plan to review: five entities — Student, Class, Time slot, Attendance, Payment — and their links: a student enrols in a class, a class has a teacher and a slot, an attendance record ties a student to a dated session, a payment ties a family to a term.
The states inferred from the text are laid out in the plan: an attendance record is present, absent or made up; a payment is paid, pending or late. The three requested indicators — this week's attendance, pending make-ups, late payments — appear before anything is generated. This is the moment to add a missing concept (summer workshops, say); after that, what gets built is what was validated.
- Entities: Student, Class, Time slot, Attendance, Payment
- Relations: student → class; class → teacher, slot; attendance → student; payment → student
- Statuses: present / absent / made up; paid / pending / late
- Indicators: this week's attendance, due make-ups, late payments
Navigation: the school in five sections
The sidebar carries the sections: Dashboard, Students, Classes, Attendance, Payments. The student list shows name, enrolled class, teacher, slot — with instant search: typing “Mar” is enough to find Margaux and Martin while a parent is on the phone.
The class list filters by discipline or teacher; the payment list filters by status, and coloured badges do the rest: an orange “Late” doesn't get lost among the “Paid”.
The student record, with attendance and payments
Margaux Lefèvre's record gathers what a notebook scatters: her contact details and her family's, her class (guitar, Tuesday 5:30 pm, clickable through to the class record), then two linked histories — her session-by-session attendance, with absences and their eventual make-up, and her term-by-term payments.
The question “where does this family stand?” is settled on a single screen: you see the May 12 absence not yet made up and the spring term paid. The relational database ties it all together — no manual carrying-over from one notebook to another.
The attendance sheet: thirty seconds, no more
The attendance entry screen is built for the classroom: open today's slot, the enrolled students appear, tick present or absent for each, save. On a phone or tablet, roll call fits in thirty seconds — the survival condition of any attendance sheet.
A recorded absence automatically feeds the pending make-up counter; when the make-up session happens, the record switches to “made up” and the counter goes down.
The dashboard: the director's three questions
The dashboard answers the three daily questions: this week's attendance rate, the number of pending make-ups, the amount of late payments — completed by headcount per discipline, computed from enrolments.
Each figure is a query on the database: the attendance sheet filled at 6 pm shows in the week's rate at 6:01. A per-discipline breakdown shows at a glance where the school is growing.
Demo data: a living school
Pupitre ships populated: some fifty plausibly named students, three disciplines, teachers, slots spread across the week, and above all a history — several months of attendance with its share of absences, some made up and some not, and payments in all three statuses.
You evaluate the application at cruising speed, not on day one: lists are full, counters show realistic values. The demo data is cleared before real use. The application lives at its dedicated URL and its complete code exports (ZIP, GitHub) — standard Next.js + Prisma.