School Photo Software · the toolchain a school runs its photography program on
The software your school runs its whole photography program on — roster to delivered order, one toolchain.
School Photo Software is the operating software for a school photography program: not a phone app, not a hosting plan, but the toolchain itself. It runs as a chain of modules, each keyed off the school roster — roster import, a consent gate enforced at the data layer, private roster-matched galleries where a family finds photos by roster name, order rails, PSPA/SPOA pro-lab output, and delivery tracking. Each school is its own tenant: one school’s data is never visible to another. The toolchain is free to run — no contract, no per-seat fee. Below, each module is named and its build status stated plainly: what is shipped, and what is honest early access.
This is the software / toolchain framing of a school photography program. The app framing is at schoolphoto.app; the hosting posture is at schoolphoto.cloud; the two-sided studio network is at schoolphoto.network. Picture day itself — one input to this toolchain — is at pictureday.software. Order rails accept no live payment today: no card is charged, and there is no live checkout.
The modules of the toolchain: what is built and what is early access
The photography program runs as a chain of modules, each keyed off the roster. The first six are shipped and running. The last two are partially shipped: the order infrastructure is built but live payment is honest-off, and delivery tracking beyond the order ledger plus outside-lab routing are early access. Each is marked honestly.
Roster import — the module every other module keys off
The toolchain starts from the school roster. A school imports its roster in the format its student information system exports; every later module resolves to a roster identifier. A gallery is a roster match, an order is placed against a roster record, and the pro-lab export is keyed by roster line. The roster is the spine of the whole program — a student who is on the roster can have a gallery, an order, and an export; a student who is not on the current roster does not. The school keeps the authoritative roster in its existing system; the toolchain reads it on import. Shipped
Consent gate — enforced at the data layer, not a reminder
A student without a completed consent record does not appear in a family-accessible gallery. That is not a policy note or a checkbox a route can forget — it is enforced in code at the data layer: the module checks the roster record’s consent status before admitting a portrait to any family-facing view. A school administrator sees which students are consent-confirmed and which are pending before the gallery opens. Consent is off by default, collected per student, and withdrawable at any time; a withdrawal removes the student from the shared view. Shipped
Private roster-matched galleries — find by name, not by face
A family finds their child’s photos by entering the child’s roster name — a roster LOOKUP, not a face match. The studio assigns each portrait to a roster record explicitly during upload, and that assignment is the access key. A portrait is never visible to any other family, never indexed in a public view, and never searchable from outside the family and the studio. Facial recognition plays no part in the matching workflow; it is off by default. Shipped
Team photos, composites, directory, and ID-card composites
From the same roster-matched portrait set, the toolchain builds the derived products a school program needs: team and group photos, class composites, the class directory, and ID-card composites. Each is assembled against the roster, so a name on a composite resolves to the same roster record the gallery and the order use. There is no re-keying between the portrait, the directory, and the ID card — they read the one roster-matched set. Shipped
School-choosable backgrounds — deterministic matting
A school selects its portrait background from a catalog of options: solid tones, school-color-derived backgrounds, and thematic choices. The studio uploads portraits with transparent-alpha cutouts, and the chosen background is composited by a deterministic matting step — the same inputs always produce the same composited portrait. PNG-alpha cutout delivery is available alongside the standard pro-lab JPG for layering uses. Background selection is a module of the toolchain, configured per school at setup. Shipped
PSPA/SPOA pro-lab output — the structured delivery file
At the end of a session the toolchain produces the structured, lab-ready output the school information system and the print lab expect: PSPA (Professional School Photographers of America) and SPOA (School Portrait Order Association) export formats, keyed by roster line. This is the file the school’s system imports for the yearbook and ID cards, and the file the lab reads to produce prints. The pro-lab output module is built and runs from the roster-matched portrait set. Shipped
Order rails / parent store — infrastructure built, payment honest-off
The order rails are built as infrastructure: product selection, the order ledger, and fulfillment tracking are present in the toolchain. The live payment rail that accepts a family’s transaction is honest-off. No card is charged today and there is no live checkout. We name that plainly rather than presenting a live parent store. The ordering surface exists as infrastructure; the payment step is the early-access leg. Early access — live payment rails Early access -- live payment rails
Delivery tracking and outside-lab routing — early access
The built order ledger records what was ordered and where it stands. Delivery tracking beyond that ledger — the family-facing status trail on a shipped order — is early access. Outside-lab routing, the ability for a program to send fulfillment to a print lab of its own choosing rather than the default, is in active development: the routing seam is designed, the production wire-up is in progress. Texted family reminders are in active development as well. Each is named as early access, not presented as live. Early access -- in active development
How a photo moves through the toolchain, module by module
The toolchain has a clear data flow. Every module projects forward from the roster; nothing is re-keyed or invented at a later stage.
- The roster is imported. The program begins with the school roster, imported in the format the school information system exports. Every later module resolves to a roster identifier, so the same student record carries through the gallery, the order, and the pro-lab export.
- Consent is collected and gated at the data layer. Families complete consent per student through the school’s own channels; the toolchain tracks the consent status on each roster record. A student without a completed consent record does not appear in a family-accessible gallery — enforced in code at the data layer, not by a reminder. The administrator sees the consent-confirmed count before any gallery opens.
- Portraits are captured and matched to the roster. After the shoot, the studio uploads portraits and assigns each one to a roster record explicitly. That assignment is the access key. There is no face scan in the matching workflow — the match is the studio’s roster assignment, and facial recognition is off by default.
- The chosen background is composited. The school’s selected background — a solid tone, a school-color-derived option, or a thematic choice — is composited onto the transparent-alpha cutout by the deterministic matting step. The same portrait and the same background always produce the same result.
- Private galleries open to families. Once portraits are matched and the consent check passes, each consent-confirmed family opens its child’s gallery by searching the roster name. Access is restricted to the family on that roster record; a portrait is visible to no other family and is never placed in a public index. Find-my-child is a roster lookup, not a face match.
- Derived products are assembled. Team photos, class composites, the class directory, and ID-card composites are built from the same roster-matched portrait set, so a name on a composite resolves to the same roster record the gallery uses.
- Orders are placed against the roster. The order rails present products and record an order against the roster record. The order ledger and fulfillment tracking are built. The live payment rail is honest-off: no card is charged today and there is no live checkout. The order infrastructure runs; the payment step is early access.
- Pro-lab output is produced. The PSPA/SPOA export produces the structured, lab-ready file keyed by roster line — the file the school information system imports for the yearbook and ID cards, and the file the print lab reads. Delivery tracking beyond the built order ledger, and outside-lab routing, are early access.
Per-school tenant isolation: one school’s data is never another school’s
The toolchain runs each school as its own tenant. Isolation is a property of the data layer, not a filter a route applies after reading. A record from one school is never visible to another school.
Isolation at the data layer, not the route
Each school is a tenant leaf. A read scoped to one school returns only that school’s roster, galleries, orders, and exports — enforced at the data layer before any application route sees the result. It is not a WHERE clause a route could omit; the isolation fires first. One school’s portraits, roster, and order history are never visible on another school’s surface.
The roster is the tenant spine
Because every module keys off the roster, tenant isolation follows the roster automatically. A gallery, an order, and a pro-lab export all resolve to a roster record that belongs to exactly one school tenant. There is no shared portrait pool across schools and no cross-school directory. The roster scopes the whole toolchain.
The school owns its data
A school owns its roster, its consent records, its galleries, and its order history. The toolchain reads the roster on import and reflects roster changes on the next import cycle; the authoritative roster stays in the school’s own system. If a school leaves, its records go with it. The toolchain is the operating software, not the owner of the school’s record.
Free to run — no contract, no per-seat fee
Running the toolchain carries no contract and no per-seat fee. A school operates the roster import, the consent gate, the galleries, the derived products, and the pro-lab output without a license charge. Pricing and checkout are not on this page; the order rails’ live payment step is honest-off. The software a school runs its program on is free to run.
Photo privacy: a roster lookup, not a face match
Student portraits are the most sensitive data the toolchain handles, and the privacy posture is built into the modules rather than bolted on. Photos and face data are never sent to an outside AI or photo company; the editing and storage steps of the toolchain run on our own private system.
Find-my-child is a roster LOOKUP, not a face match. A family finds photos by entering the child’s roster name against the school roster; the module confirms the family is the one attached to that roster record and serves only that child’s portraits. The match is the studio’s explicit roster assignment made at upload. No portrait is placed in a public index, and no portrait is visible to any family other than the one on the roster record.
Facial recognition is off by default. It plays no part in the matching workflow, the gallery, or the order module. It stays off for a child until that child’s parent opts in explicitly — an older blanket permission sitting on the roster record is not enough to switch it on. Where a parent has opted in, the face template is held only inside our own private system — never an outside company, no outside recognition service connected — and withdrawing the opt-in stops the matching. The school sets a face-data retention window, 365 days by default, and that window is what marks a template due for destruction. The step that destroys the stored template is not finished, and we are not going to tell you it runs nightly when it does not; the cleanup job halts and raises an alert rather than record a deletion it cannot carry out. The template is never public and never sold.
What does work end to end is suppression. A do-not-publish decision drops that student’s images and name from the digital edition, from the reader, and from the print belt — one child suppressed everywhere, without touching any other student’s photos. That is a separate promise from the face-template one, and it is the one we can show a family working.
Consent is collected per student, tracked per roster record, off by default, and withdrawable at any time. A withdrawal removes the student from the shared gallery. The consent gate is enforced at the data layer, so the privacy posture holds even for a route that forgot to check.
The order rails: built as infrastructure, payment honest-off
The order module is real infrastructure in the toolchain — product selection, the order ledger, and fulfillment tracking. The step that accepts a live family payment is honest-off, and we say so plainly rather than presenting a live parent store.
Orders are placed against the roster
An order is recorded against a roster record, so the product a family selects resolves to the same student the gallery and the pro-lab export use. The order ledger records what was selected and where the order stands. There is no re-keying between the gallery and the order; both read the one roster-matched set.
Live payment is honest-off
The payment rail that would accept a family’s transaction is present in the toolchain as infrastructure but is not enabled for live use. No card is charged today. There is no live checkout and no live ordering. We name this plainly. Early access — live payment rails
Fulfillment tracking on the built ledger
The order ledger tracks fulfillment status on the records it holds. A family-facing delivery status trail beyond that built ledger is early access. The pro-lab output that a fulfilled order depends on — the PSPA/SPOA export — is shipped; the delivery tracking surface layered on top of it is the early-access step.
Outside-lab routing is in development
Outside-lab routing — sending fulfillment to a print lab a program chooses rather than the default — is in active development. The routing seam is designed in the fulfillment module; the production wire-up to external lab systems is in progress and not yet live. Until it is, fulfillment runs through the configured default. Texted family reminders are in active development on the same footing.
Pro-lab output: the file the lab and the school information system expect
The pro-lab output module produces the structured delivery file at the end of a session. PSPA (Professional School Photographers of America) and SPOA (School Portrait Order Association) export formats define how a portrait set is packaged for a school information system and a print lab. The toolchain produces that structured file keyed by roster line, so the portrait a family sees in the gallery and the portrait the lab prints come from the same roster-matched set.
The export is what the school information system imports for the yearbook and for ID cards, and what the print lab reads to produce an order. Because it is keyed by roster line, a portrait, a directory entry, and an ID-card composite for the same student all resolve to the same roster record — there is no re-keying between the toolchain and the lab. The pro-lab output module is built and runs from the roster-matched portrait set.
Background selection, alpha-cutout delivery, and the derived products — team photos, composites, the directory, and ID-card composites — all feed the same output. A school configures its export format and its background at setup; the toolchain produces the lab-ready file at session end.
Common questions
What is School Photo Software?
It is the software a school runs its whole photography program on — the toolchain, module by module: roster import, a consent gate enforced at the data layer, private roster-matched galleries, derived products (team photos, composites, directory, ID cards), school-choosable backgrounds, order rails, and PSPA/SPOA pro-lab output, with per-school tenant isolation. It is not a phone app, not a hosting plan, and not a studio marketplace. It is the operating software a school office runs its program on, and it is free to run.
How is this different from schoolphoto.network?
schoolphoto.network is the two-sided studio network where independent photographers and the schools they serve meet. This page is the software toolchain a single school runs its program on, framed for the buyer at the school. The network is the marketplace; this is the operating software. They share the same privacy posture — consent-gated, roster-matched galleries with no face match in the matching workflow — but the framing here is the toolchain, not the network.
How is this different from pictureday.software?
pictureday.software is the picture-day event orchestration surface: the day itself, check-in, and the day-of workflow. This toolchain is the whole year-round program, of which picture day is one input. The through-line here is the chain of modules from roster import to the delivered order — the order rails, the pro-lab output, and delivery tracking — not the logistics of a single shoot day.
How does the consent gate work?
A student without a completed consent record does not appear in a family-accessible gallery. It is enforced in code at the data layer: the module checks the roster record’s consent status before admitting a portrait to any family-facing view. It is not a reminder and not a checkbox a route can forget. An administrator sees the consent-confirmed count before the gallery opens. Consent is off by default, collected per student, and withdrawable; a withdrawal removes the student from the shared view.
How does a family find their child’s photos if there is no face match?
Find-my-child is a roster LOOKUP. A family enters the child’s roster name against the school roster; the module confirms the family is attached to that roster record and serves only that child’s portraits. The studio assigns each portrait to a roster record explicitly at upload, and that assignment is the access key. Facial recognition is off by default and plays no part in the matching workflow.
Is facial recognition used anywhere?
Facial recognition is off by default. It plays no part in the matching workflow, the gallery, or the order module. If a parent opts in to a face-assisted photo-finding convenience, the face template is held only inside our own private system — never an outside company, no outside recognition service connected — and withdrawing the opt-in stops the matching. The school sets a face-data retention window, 365 days by default, and that window is what marks a template due for destruction. Destroying the stored template itself is a step we have not finished, so we do not claim it happens on a schedule; the cleanup job halts and raises an alert rather than record a deletion it cannot carry out. Photos and face data are never sent to an outside AI or photo company.
Can a family order prints today?
Not for live payment. The order rails — product selection, the order ledger, and fulfillment tracking — are built as infrastructure. The live payment rail that would accept a family’s transaction is honest-off: no card is charged today and there is no live checkout. We say so plainly. The order infrastructure runs; the payment step is the early-access leg.
What is PSPA/SPOA pro-lab output and why does it matter?
PSPA (Professional School Photographers of America) and SPOA (School Portrait Order Association) export formats define how a portrait set is packaged for a school information system and a print lab. The toolchain produces that structured file keyed by roster line at the end of a session — the file the school system imports for the yearbook and ID cards, and the file the lab reads to produce prints. It is shipped and runs from the roster-matched portrait set.
How does per-school tenant isolation work?
Each school is its own tenant leaf. A read scoped to one school returns only that school’s roster, galleries, orders, and exports, enforced at the data layer before any route sees the result. Because every module keys off the roster, isolation follows the roster automatically: a gallery, an order, and an export all resolve to a roster record that belongs to exactly one school. One school’s data is never visible on another school’s surface.
What does it cost to run?
The toolchain is free to run — no contract and no per-seat fee to operate the roster import, the consent gate, the galleries, the derived products, and the pro-lab output. Pricing and checkout are not on this page. The order rails’ live payment step is honest-off. To talk through the current state honestly, get in touch.
What is built today and what is early access?
Built and running: roster import, the consent gate at the data layer, private roster-matched galleries, team photos and composites and the directory and ID-card composites, school-choosable backgrounds with deterministic matting, PSPA/SPOA pro-lab output, and per-school tenant isolation. Early access: the order rails’ live payment (built as infrastructure, no card charged today), delivery tracking beyond the built order ledger, outside-lab routing, and texted family reminders. Each module above states its status plainly.
Related surfaces
The same school photography program is framed several ways across the family of sites. These destinations cover the app, the hosting posture, the US-market framing, the studio network, and the picture day itself.
schoolphoto.app
The app framing of the same school photography program — the same roster-matched, consent-gated posture, presented as the application a school uses rather than the toolchain it runs on.
schoolphoto.cloud
The hosting and storage posture for the program: where the photos and records live, on our own private system, with editing and storage never sent to an outside AI or photo company.
schoolphotos.us
The US-market framing of school photography — the same privacy-first program spoken to a US school audience, distinct from this software / toolchain framing.
schoolphoto.network
The two-sided studio network where independent photographers and the schools they serve meet on one private system. The marketplace side; this page is the school’s own operating software.
pictureday.software
The picture-day event orchestration surface: check-in, day-of consent, and the shoot itself. Picture day is one input to this toolchain; that surface covers the day, this one covers the year-round program.
What is built and what is honest-off
Roster import, the consent gate enforced at the data layer, private roster-matched galleries (find-my-child is a roster lookup, not a face match), team photos, composites, the class directory, and ID-card composites, school-choosable backgrounds with deterministic matting, PSPA/SPOA pro-lab output, and per-school tenant isolation are built and running today. The toolchain is free to run — no contract, no per-seat fee. The order rails are built as infrastructure, but the live payment rail is honest-off: no card is charged today and there is no live checkout. Delivery tracking beyond the built order ledger, outside-lab routing, and texted family reminders are early access: we name them plainly. Photos and face data are never sent to an outside AI or photo company; editing and storage run on our own private system. Facial recognition is off by default; where a parent opts in, the face template is held only inside our own private system with no outside recognition service connected, and withdrawing the opt-in stops the matching. The school’s face-data window — 365 days by default — is what marks a template due for destruction, and the step that destroys the stored template is not finished: the cleanup job halts and raises an alert rather than record a deletion it cannot carry out, and we would rather show a school that alarm than a checkmark. Do-not-publish suppression — dropping a student’s images and name from the digital edition, the reader, and the print belt — is built and running today. No competitor brand names appear here. Money, pricing, and checkout are not on this page.