Montessori-native

What Montessori Schools Actually Need From Their Software

I asked a head of school recently to list the systems her school runs on. She got to eleven before she stopped, and she was not exaggerating for effect. There was one platform for the website, another for admissions and billing, another for family communication and fundraising, another for lesson records, another for the middle and high school, and separate arrangements for tuition, timesheets, event tickets and the annual dance. Her teachers had four logins. Her families had three. Her bookkeeper reconciled across all of it by hand.

Nobody chose that. It accumulated. Each system solved one real problem in the year it was bought, and none of them were ever going to talk to each other.

This is the ordinary condition of a Montessori school, and it has two costs. The obvious one is money and hours. The one that matters more is that the truth about a child is now stored in eleven places, and no single person can see it.

Montessori-native is not a feature list

Most school software was built for a graded, subject-divided, grade-book school, and then adapted. You can tell, because of what it asks you to enter. It wants a grade level. It wants a class period. It wants an assignment with a score. It wants an end-of-term average.

A Montessori school does not have those things. It has three-year cycles and mixed-age communities. It has individual lesson records, not shared assignments. It has an uninterrupted work cycle, not periods. It has observation notes that matter more than any score, and a materials sequence a child moves through at her own pace.

So the school does the thing every Montessori school does with adapted software. It translates. It calls the Primary community a grade. It converts a lesson given into an assignment completed. It writes narrative progress into a comment box built for one sentence. And year by year the record of what actually happened in the classroom gets a little further from the practice it was supposed to describe.

That is the real cost of software that was not built for this. Not missing features. It quietly makes you describe your school as something it is not, and then that description is what the state sees, what the board sees, and what next year’s guide inherits.

MMAP was built the other way around. Lesson records, observation, the work cycle, the three-year arc, mixed-age communities and materials sequences are the data model, not a vocabulary layer over somebody else’s. When a guide records a lesson for a group and tags the eight children it was for, MMAP writes it into eight individual progress records and puts it on the calendar once. That is not a clever feature. That is just what it means to build for how the work is actually done.

Everything the operations side demands, without giving that up

The trap in Montessori-specific software has usually been that you get the pedagogy and lose the operations. Beautiful record keeping, and then you still need something else for admissions, tuition, payroll hours, attendance, compliance, conferences, family communication and the board report.

MMAP carries the operational load. Admissions from first inquiry through tour through enrollment, with the tour notes still attached to the family record two years later. Attendance and compliance reporting the state will accept. Tuition and payments. Staff hours. Family portal and messaging. Governance and leadership reporting at the top tier for the people who have to answer to a board.

Four tiers, each including everything below it. Surveyor at two dollars per student per month for classroom practice. North Star at three for the full student information system and family communication. Mapmaker at five for admissions, staffing and reporting. Atlas at seven for leadership, governance and analytics. A hundred-student school on the full stack pays less per month than most schools currently pay for two of their eleven systems.

Built to suit, which means we actually ship

Every vendor says they listen. Here is what it means here.

The head of school with eleven platforms told me her guides needed to plan by day, group and individual together, partly because she wanted intention in the work cycle and partly because her state early childhood representative asks to see a weekly plan on site visits. She did not want a teacher maintaining a separate spreadsheet just to satisfy an inspector. The Weekly Plan view was live before our next conversation.

In the same exchange she asked for a kiosk-locked time clock, then thought about it and said she did not need it, she would just talk to anyone punching in from their couch. We dropped it. A feature that mostly creates rigidity is worse than no feature, and a vendor who builds everything requested is not listening either, they are just billing.

That is the arrangement. Tell us what the work actually requires. We build what turns out to be true for Montessori schools generally, discovered through your specific problem, and we are honest with you about what exists today, what is scoped, and what would be built for you before you go live. You should never be relying on a promise to run your school.

The trade

You can keep eleven systems, or you can run on one that was built for the way you already work. The saving is real, but it is not the point. The point is that when a family asks a question, or a guide wants to know what happened last year, or the board wants to know whether the school is actually doing what it says, there is one place to look and the answer is in the school’s own language.