How to make school software

Teams that “make school software” usually underestimate the holiday master, mid-year joiners, two-guardian contacts, and publish gates.

A CRUD app for students is not a school system. The system is the handoff: applicant becomes roster row becomes fee account becomes attendance denominator. Do this against working days on one student record, with publish gates, not a generic weekday grid. Named facts: working days, one student record, publish gates. Name the owner before the first family sees a receipt.

They can build a list of names. They will not finish fee proration, two guardians, and exam candidate lists.

Hard-coding Monday–Friday.
One email field per family.
Claiming a general ledger you did not build.

Model working days, not weekdays

Attendance percentages lie without an official exception calendar. Store official exceptions on a holiday master a named role publishes. Attendance percentages that assume every weekday was open will not survive the first closure.

For making school software, “Model working days, not weekdays” still has to survive a mid-year joiner and a working-day exception on one student record. Refuse this shortcut: Hard-coding Monday–Friday. Can a college intern build this in a summer? They can build a list of names. They will not finish fee proration, two guardians, and exam candidate lists. Named facts: working days, one student record, publish gates.

“Model working days, not weekdays” for making school software fails when this is skipped: The product is the handoff. An applicant becomes a roster row, that row becomes a fee account, and that account becomes the attendance denominator on working days.

Generators do not own the holiday master. Schools still need named workflows.

Model working days, not weekdays
Hard-coding Monday–Friday.
Named facts: working days, one student record, publish gates.

One person, many contacts

Two households, one child, separate logins. A father/mother pair of fields will not survive custody. Model two households, one child, and separate logins. A single father/mother pair of fields fails the first custody arrangement and the first pickup list.

For making school software, “One person, many contacts” still has to survive a mid-year joiner and a working-day exception on one student record. Refuse this shortcut: One email field per family. What about AI generating the SIS? Generators do not own the holiday master. Schools still need named workflows. Named facts: working days, one student record, publish gates.

“One person, many contacts” for making school software fails when this is skipped: The product is the handoff. An applicant becomes a roster row, that row becomes a fee account, and that account becomes the attendance denominator on working days.

As soon as a parent receipt has to match the bursar. That is week one.

One person, many contacts
One email field per family.
Named facts: working days, one student record, publish gates.

Charges on the student

Transport and hostel are heads, not informal cash. Receipts must match finance. Transport and hostel are fee heads on the student. The receipt the family downloads has to be the same object finance already posted.

For making school software, “Charges on the student” still has to survive a mid-year joiner and a working-day exception on one student record. Refuse this shortcut: Claiming a general ledger you did not build. When should a school buy instead of build? As soon as a parent receipt has to match the bursar. That is week one. Named facts: working days, one student record, publish gates.

“Charges on the student” for making school software fails when this is skipped: The product is the handoff. An applicant becomes a roster row, that row becomes a fee account, and that account becomes the attendance denominator on working days.

They can build a list of names. They will not finish fee proration, two guardians, and exam candidate lists.

Charges on the student
Claiming a general ledger you did not build.
Named facts: working days, one student record, publish gates.

Publish is an action

Saved marks are drafts. Families treat what they saw as official. Saved marks are drafts. Publish is a separate action. Families will treat the first version they saw as official, so a correction needs a trail.

For making school software, “Publish is an action” still has to survive a mid-year joiner and a working-day exception on one student record. Refuse this shortcut: Hard-coding Monday–Friday. Can a college intern build this in a summer? They can build a list of names. They will not finish fee proration, two guardians, and exam candidate lists. Named facts: working days, one student record, publish gates.

“Publish is an action” for making school software fails when this is skipped: The product is the handoff. An applicant becomes a roster row, that row becomes a fee account, and that account becomes the attendance denominator on working days.

Generators do not own the holiday master. Schools still need named workflows.

Publish is an action
Hard-coding Monday–Friday.
Named facts: working days, one student record, publish gates.

How this playbook changes for a real campus

making school software still starts from the holiday master, not a borrowed weekday grid. The product is the handoff. An applicant becomes a roster row, that row becomes a fee account, and that account becomes the attendance denominator on working days.

Working days, one student record, and publish gates are the checks. Receipts have to match finance before families see a result.

Hard-coding Monday–Friday. One email field per family. Claiming a general ledger you did not build. Named facts: working days, one student record, publish gates.

Generators do not own the holiday master. Schools still need named workflows.

Model working days, not weekdays
Named facts: working days, one student record, publish gates.
the boards the campus reports to

Where this usually breaks

Hard-coding Monday–Friday. One email field per family. Claiming a general ledger you did not build.

A second spreadsheet for the real list is the usual failure. Named facts: working days, one student record, publish gates.

making school software still fails when this is skipped: The product is the handoff. An applicant becomes a roster row, that row becomes a fee account, and that account becomes the attendance denominator on working days. Saved marks stay drafts until the school publishes them.

If you are a school, do not start a software company. Use Schoolyi for operations and keep your board pedagogy. If you are a vendor, these constraints are the product.

Hard-coding Monday–Friday.
One email field per family.
Claiming a general ledger you did not build.

How Schoolyi fits

If you are a school, do not start a software company. Use Schoolyi for operations and keep your board pedagogy. If you are a vendor, these constraints are the product.

Open /platform after you can describe the awkward case for making school software. This page is a playbook, not a feature grid. Name the owner in the demo. Named facts: working days, one student record, publish gates.

That walkthrough still uses the holiday master the school will go live on and the fee heads families can see on a receipt.

They can build a list of names. They will not finish fee proration, two guardians, and exam candidate lists.

Playbook: /how-to/build-school-software
Product: /platform
Book a demo with your awkward case, not a slide deck

Questions

Can a college intern build this in a summer? They can build a list of names. They will not finish fee proration, two guardians, and exam candidate lists.

What about AI generating the SIS? Generators do not own the holiday master. Schools still need named workflows. Named facts: working days, one student record, publish gates.

The product is the handoff. An applicant becomes a roster row, that row becomes a fee account, and that account becomes the attendance denominator on working days. Named facts: working days, one student record, publish gates. Ask these before the demo.

When should a school buy instead of build? As soon as a parent receipt has to match the bursar. That is week one. Named facts: working days, one student record, publish gates.

Can a college intern build this in a summer? They can build a list of names. They will not finish fee proration, two guardians, and exam candidate lists.
What about AI generating the SIS? Generators do not own the holiday master. Schools still need named workflows.
When should a school buy instead of build? As soon as a parent receipt has to match the bursar. That is week one.

Bring this playbook to a demo

The product is the handoff. An applicant becomes a roster row, that row becomes a fee account, and that account becomes the attendance denominator on working days. If you are a school, do not start a software company. Use Schoolyi for operations and keep your board pedagogy. If you are a vendor, these constraints are the product. Named facts: working days, one student record, publish gates. Book the demo with that owner in the room.

Score statutory filing and hardware as not met unless the deployment actually has them. Publish gates still decide what families see.

Model working days, not weekdays

Open /platform
Book a demo with the awkward case
Named facts: working days, one student record, publish gates.

How to make school software