School Software · K–12 module catalog
Every module a school runs — what is built, what it does, and where to find the full story.
This is a plain catalog for administrators and superintendents who want a direct answer: what software does a school need, and does this platform cover it? The eleven modules below are all built code that runs today. Each has an honest one-line status. No brand theatrics. If you want the full platform story and the persuasion case, that is at homeroom.software. If you want to see how the platform works across every type of school, that is at allschool.software. This page is the catalog — the list you came for.
Student records imported once from a roster; the same roster runs every module listed here. Per-module status is honest: “live today” means the code runs; “early access” means it is built but not yet generally available. Money, checkout, and pricing are not on this page.
The eleven built school-software modules
These are the modules that cover what a school runs. All eleven are built code that exists and runs today. The status line on each is honest: “live today” means it is in active use; “early access” on a sub-feature means that specific piece is built but not yet generally available. No module on this list is a roadmap item.
Student records and directory
The foundational record: name, grade, homeroom, guardian contacts, enrollment status, and consent flags. Every other module reads from this one roster — imported once from whatever the school uses today, not re-keyed for each tool. The directory is generated directly from the same record: a class list, a staff directory, or a grade-band roster, all from one source. A change to the roster reflects everywhere. The FERPA single-school privacy wall means no record from one school is ever visible to another school on the platform, enforced at the data layer.
Live today
Publications — yearbook, newspaper, literary magazine, and online editions
The production editor for the whole range of school publications: the annual yearbook, a student newspaper, a literary magazine, and online editions. An adviser assigns staff to sections; a section editor owns their coverage and is accountable for it; the adviser’s proof-approval step is a feedback-and-revision loop, fail-closed so the standard is enforced before anything goes to print or publishes online. Student portraits from picture day flow directly into the yearbook without a second import. Version history lets staff experiment safely. The print preflight is fail-closed: a publication with a missing portrait, an unsigned release, or a consent gap cannot proceed to print.
Live today
Picture day
Picture-day portraits are captured on a private system and bound to the student roster at the moment of capture. The same photo that runs through the pipeline feeds the directory, the ID card, the yearbook, and the family gallery — one capture event for every downstream use. Consent is checked before a portrait can appear in a shared publication or a parent gallery: no consent record, no appearance. A parent finds their child by a roster lookup (name, grade, homeroom), not a face match. There is no biometric template. The picture-day scheduling module books time slots by grade or homeroom. A studio runs the day, the school runs it, or a mix-and-match arrangement handles each part separately. The parent-facing portrait storefront and the revenue split are in early access.
Live today Portrait storefront: early access
Cafeteria and lunchroom
The cafeteria module covers the daily operational picture a lunchroom needs: student account lookup by roster, meal status by period, and the record that ties a lunch count to the student list the front office already has. The roster is the same record the rest of the platform reads — no separate import for the cafeteria. A student added to the roster is immediately visible to the cafeteria module. A student removed from enrollment is immediately out of the cafeteria count. The module does not process payments directly; it connects to the school’s existing lunch account or payment processor as a data layer on top of the roster.
Live today
Library and media center
The library module tracks the school’s collection, circulation, and patron records against the same student roster. A student checks out a title; the circulation record ties to their roster entry. Overdue tracking, holds, and collection management all read from the same roster the front office uses. The media center side covers equipment checkout and production-lab scheduling through the shared slot engine. A student or staff member who holds a library item or a camera kit from the media center has that checkout visible to the library staff without a separate patron lookup.
Live today
Fundraising
The fundraising module ties a campaign — a drive, a sale, a sponsor push — to the school’s existing roster and program structure. A yearbook-for-every-child campaign, a module sale, or a publication pre-order can all route through the fundraising layer. Proceeds are tracked against the campaign goal; the ledger records what came in and from which participant. The school’s program receives the funds; the ledger routes the payment directly to the purchase it is covering rather than accumulating in a separate account the school has to draw down. Studio and rep wallet balances can fund a school purchase from the earned commission balance; a shortfall routes to a payment option.
Live today
Scheduling
The scheduling core is a single canonical slot, booking, and availability engine that runs eight K-12 booking surfaces: period scheduling, picture-day slots, room and facility booking, conference appointments, senior portrait sessions, tryout and audition slots, activity scheduling, and the media-center equipment calendar. There are two booking families: the window-overlap model (room and facility bookings, conference scheduling) and the fixed-slot identity model (picture-day, senior portraits, admissions appointments). Both run on one engine. A teacher’s period schedule, a parent conference block, and a picture-day time slot are all the same primitive with different surface metadata.
Live today
Student ID cards
The ID-card module composites a student’s card from what is already on file: the roster entry (name, grade, homeroom, enrollment status) and the portrait from picture day. One capture event on picture day feeds the directory, the yearbook, and the ID card — there is no second picture-day session for IDs. The school’s template (branding, layout, barcode format) is applied at composite time. Print preflight is fail-closed: a card cannot go to print if the portrait is missing or the roster entry is incomplete. A student added mid-year can have an ID composited from a supplemental capture without running a full picture day.
Live today
Ad sales
The ad-sales module manages the business side of a publication’s advertising program: prospect tracking, order entry, ad sizing and placement, and the approval workflow between the sales team and the adviser. A student ad-sales team can use the module to log prospects, record commitments, and route ad copy to the adviser for approval before it is placed in the layout. The ledger records what was sold and what was paid; the ledger balance is available to the yearbook or publication budget without a separate accounting step. Ad copy flows into the production editor as a placed element in the section it was sold for.
Live today
Family communication
The family communication module routes messages to consented guardian recipients through the canonical notify chokepoint. A guardian is a consented contact on the student’s roster record; the system resolves recipient addresses from the record rather than from a freeform list. Minors are default-deny: a message intended for a student’s household reaches only the consented guardians on file. The routing logic and the recipient-resolution step are built. Texted alerts to family — the outbound SMS/push wire — are in early access pending provider provisioning. No outbound message leaves the system until the wire is connected; the page names that plainly.
Live today Texted alerts to family: early access
Student activities — clubs, teams, theatre, and rosters
The activities module manages the roster and eligibility picture for clubs, sports teams, theatre productions, and other student programs. An activity roster lives on the same roster the rest of the platform uses; a student joins a club and the membership is visible to the adviser without a separate sign-up system. The academic eligibility engine answers a deterministic yes/no question — is this student currently eligible to participate? — from the school-provided criteria, without reading a live gradebook. Rehearsal planning, call sheets, and director’s notes for theatre productions are built. The activity scheduling surface books tryouts, auditions, and rehearsal blocks on the shared slot engine.
Live today
One roster, imported once
Every module on this page reads from the same student record. A school imports its roster once — from whatever student information system it already uses, in the format that system exports — and every module has the student list from that point forward. A student added to the roster mid-year is immediately visible to the cafeteria, the library, the ID-card pipeline, and every other module. A student who withdraws is removed everywhere at once.
The record holds what each module needs: name, grade, homeroom, guardian contacts, enrollment status, and the consent and permission flags that gate what a student can appear in. The consent gate is the same check whether a portrait is going into a yearbook, a parent gallery, or an ID card. There is no second import for each module and no reconciliation step between systems that each hold a partial copy of the same list.
This is an SIS-adjacent design, not a student information system replacement. The authoritative enrollment record stays wherever the school keeps it today. The platform imports from that source; it does not duplicate it or replace it. A change to the authoritative enrollment record is reflected on the next import cycle. The school does not need to maintain two enrollment databases.
How the catalog fits together
The modules are not eleven separate products that happen to share a name. They share one data model. The portrait from picture day is the same file that feeds the directory, the ID card, the yearbook, and the parent gallery. The scheduling slot that books a picture-day appointment is the same primitive that books a conference, a senior portrait session, and a facility reservation. The ledger that records an ad sale is the same ledger that records a fundraising contribution and a print order.
The consequence is that a change in one place propagates correctly. A student added to the roster does not need to be added separately to the cafeteria system, the library patron list, and the activity roster. A portrait updated at retake day flows into the directory, the ID card, and the yearbook without a manual re-association. A consent withdrawal removes the student from the yearbook, the parent gallery, and the portrait storefront at once.
From a superintendent’s perspective, this means one place to look for the status of any module, one import to maintain, and one privacy posture to audit rather than eleven separate vendor relationships to review.
For the full platform story — the brand framing, the product case, and the commercial details — the right destination is homeroom.software. For the school-type breadth question (does this cover our preschool? our district? our alternative program?), the right destination is allschool.software. This catalog page stays on the question it was built to answer: what modules are covered and what is their honest status.
Honest status by module
The table below names exactly what is live today and what is in early access for each module. Nothing on this page is a roadmap item; every row describes code that exists and runs.
| Module | Live today | Early access |
|---|---|---|
| Student records and directory | Core record, roster import, directory generation, single-school privacy wall. | — |
| Publications | Production editor, section ownership, adviser proof loop, print preflight, fail-closed consent gate, version history. | — |
| Picture day | Private-system capture pipeline, roster-bound portraits, consent gate, parent gallery, directory composites, ID-card composites, team photos, subject-sovereign proofing. | Early access Parent-facing portrait storefront and revenue split. |
| Cafeteria and lunchroom | Student lookup by roster, meal status by period, lunch count from roster. | — |
| Library and media center | Collection tracking, circulation, patron records on roster, overdue tracking, media center equipment checkout. | — |
| Fundraising | Campaign tracking, ledger, proceeds routing, studio and rep wallet gifting. | — |
| Scheduling | All eight booking surfaces, window-overlap and fixed-slot identity models, period scheduling, picture-day slots, room booking, conference appointments, senior portrait sessions, activity scheduling. | — |
| Student ID cards | Composite pipeline from roster plus portrait, school template, print preflight, mid-year supplemental capture. | — |
| Ad sales | Prospect tracking, order entry, ad sizing and placement, approval workflow, ledger, ad copy flow into layout. | — |
| Family communication | Recipient resolution from consented guardian record, routing logic, consent gate, minor default-deny. | Early access Texted alerts to family (outbound SMS/push wire pending provider provisioning). |
| Student activities | Activity and production rosters, eligibility engine, rehearsal planning, director’s-note engine, call sheets, activity scheduling. | — |
Common questions
Is this a student information system?
No. The platform is SIS-adjacent: it imports from whatever student information system the school already uses and reads from that roster across every module. It does not replace the authoritative enrollment record. A school continues to maintain enrollment in its existing system; the platform reads from that source on import and reflects changes on the next cycle.
Are all eleven modules actually built?
Yes. Every module listed on this page is code that exists and runs. Some sub-features — the portrait storefront under picture day, and texted family alerts under family communication — are in early access: built but not yet generally available. The status line on each module names this plainly. Nothing on this page is a roadmap promise.
Does a school have to use all eleven modules?
No. The modules share a data model, not a mandatory activation sequence. A school can start with the modules it needs today and add others as its program expands. The roster import that enables one module enables all of them, so the marginal cost of adding a second or third module is lower than adopting each from a separate vendor.
What is the difference between this page and homeroom.software?
homeroom.software is the flagship brand home: the persuasion case, the product story, and the commercial details for the platform. This page is the plain catalog: what modules are covered and what is their honest status. If you are evaluating whether the platform covers what your school needs, this page answers that question directly. If you want to understand the full product case, homeroom.software is the right destination.
What is the difference between this page and allschool.software?
allschool.software answers the school-type breadth question: does the platform work for a preschool, a K-8, a district, an alternative program? This page answers the module-coverage question: what software categories are included? The two pages are complementary. This catalog does not repeat the school-type framing; allschool.software does not repeat the module list.
What does “early access” mean on this page?
Early access means the feature or sub-feature is built code that runs, but it is not yet generally available. A school partner in early access can use it today; a school that is not yet on the platform will get it when it joins. “Early access” on this page is never a roadmap promise — it is always a built feature at a specific availability stage.
Where do I see the picture-day module in more detail?
The picture-day module has its own product home at pholio.photos, which covers the privacy-first school photography pipeline in detail: the private-system capture, the consent gate, the roster-bound gallery, and the studio operating model. The module listed here is the same pipeline; pholio.photos is the more detailed product front door for schools and families who want the full account.
How does the consent system work across modules?
Consent is enforced at the data layer, not at the module layer. A student’s consent record is a set of flags on the roster entry: can their portrait be published, can their portrait be sold, can they appear in a shared publication. Every module that touches that student’s portrait or appearance reads the same consent record. A consent withdrawal removes the student from the yearbook, the parent gallery, and the ID-card queue at once, because all three read from the same flag. There is no per-module consent setting to synchronize.
Who controls student data on this platform?
The school remains the FERPA custodian of its students’ records and the data controller of their images. The platform processes records on behalf of the school under a school-official relationship. The single-school privacy wall means a record from one school is never visible to another school on the platform, enforced at the database layer. No student record commingles across school tenants.
Where to go next
This catalog answers the module-coverage question. These destinations answer the questions that follow from it.
homeroom.software
The flagship platform brand home: the full product story, the persuasion case, and the commercial details for the platform behind these eleven modules.
allschool.software
The school-type breadth angle: every kind of school from preschool through district, and how the platform adapts to each.
pholio.photos
The picture-day module’s own product home: the privacy-first school photography pipeline in detail, for families and schools.
schedule.software
The scheduling module in detail: the canonical slot, booking, and availability engine that runs all eight K-12 booking surfaces.
Student Records
The official student record the whole platform reads from: the roster, guardian contacts, terms, and the single-school FERPA privacy wall.
What is built and what is honest-off
All eleven modules on this page — student records and directory, publications, picture day, cafeteria and lunchroom, library and media center, fundraising, scheduling, student ID cards, ad sales, family communication, and student activities — are built code that runs today. The sub-features in early access are named on each card: the parent-facing portrait storefront and four-way revenue split under picture day, and texted family alerts under family communication. Money, checkout, and pricing information are not on this page. No competitor names appear on this page. The platform is from Stanley Studios; homeroom.software is the flagship brand home. This page is the catalog — the plain list a superintendent types “school software” to find.