photog.software · School picture day · Solo & small-shop photographers · Early access · 2026

School Photography Made Private — consent that makes picture day faster, not just compliant

photog.software is the picture-day platform for the solo photographer and small shop: consent collection before any portrait is shared, roster-driven capture with QR/barcode student-to-photo matching, private parent proof galleries, on-demand print fulfillment, and PSPA/SPOA yearbook export with a consent audit log included. The differentiator is the frame: consent is not a compliance checkbox, it is the mechanism that makes the session run cleaner. A pre-session consent list means no wasted shots of opted-out students, less post-capture culling, and an irrefutable audit record before the yearbook goes to print. Privacy is the lead. Efficiency is the bonus. Early access — no pricing commitment, no signup, no live payments today.

Book a conversation How it works

Consent-firstpre-session consent list — no wasted shots, no post-capture culling of opted-out students

No face scanQR/barcode matching at capture — no facial recognition in the matching workflow; any face lane is off by default

Exact-cent splitphotographer earns the larger leg; school earns a fundraising leg; the platform earns the residual left after those legs — computed last, shown in the breakdown

PSPA/SPOA exportyearbook-ready format + consent audit log included with every session export

How it works

Four steps — from consent collection to yearbook export

photog.software runs the picture-day workflow in four stages: consent before any portrait is taken, roster-matched upload on the day, private parent proofs and ordering, and yearbook-ready export with a consent audit log. Every stage is described as it is built today.

Step 1 · Consent collection — before picture day

The session opens with consent, not the camera. Before picture day, every parent on the school roster receives a consent request: opt in to allow portraits to be shared with the school, ordered by the family, and included in the yearbook. The photographer receives a session-day consent list that shows exactly who has opted in, who has opted out, and who has not yet responded. An opted-out student is not photographed for the school record — saving the photographer time on the day and protecting the school from yearbook liability. Consent is affirmative, per-student, granular, and revocable: a parent can withdraw at any time, and the revocation takes effect immediately at the data layer.

Step 2 · Photographer uploads — session day, roster-matched

On picture day, each student gets a session card with a QR code or barcode that ties back to their roster entry. The photographer scans or reads the code at capture; every portrait lands matched to its student from the moment of upload. Matching is a QR/barcode read at capture, not a face comparison — there is no face-identification pass and no AI guess in this picture-day workflow. Any separate face-matching lane is off by default and opt-in only. Red-flag detection runs at session close: any portrait with no roster match surfaces as an unmatched shot; any roster entry with no portrait surfaces as a missing student. Both are resolved before the photographer leaves the school. Once the upload is validated, the photographer’s work on the day is done — the platform handles proofing, ordering, and export downstream.

Step 3 · Parent ordering — private proofs, family order

Each consented student’s proofs land in a private gallery accessible to their family by roster name. There is no browsable feed of portraits and no face-based search: a family who opted in sees their child’s proofs only; a family who did not consent sees nothing. The ordering interface presents the photographer’s package options — print packages, digital downloads, and any add-ons configured for the session. The gallery and ordering interface are built on the platform’s commerce substrate. The payment rail that processes family orders is honest-off: not enabled for live transactions today. When the payment rail is enabled, the photographer’s earnings leg, the school’s fundraising leg, and the platform’s residual distribute automatically via the split engine.

Step 4 · Yearbook export — consent-audited, PSPA/SPOA format

At session close, the yearbook export produces every consented portrait in PSPA/SPOA format alongside a bulk metadata file mapping each portrait to its roster entry — student name, grade, teacher, and class — in the column structure yearbook production vendors expect. Only students with a completed consent record appear in the export. The school or yearbook adviser receives a consent audit log with the image files: proof of consent for every portrait delivered to the print vendor. The export also generates the retake list: unmatched shots and missing students flagged at session close, so the adviser knows exactly what to schedule for retakes. Export, consent audit log, and retake flag are built and production-ready.

The full platform

Five engines — honest about what is built and what is coming

Every feature is labelled honestly: Built means the underlying engine is production-ready. In development means the surface, wire-up, or routing integration is in active build. We do not claim otherwise.

Private parent proof galleries and ordering — gallery built, payment honest-off

After session upload, each consented student’s proofs are available to their family in a private gallery accessible by roster name. There is no public gallery, no browsable feed of student portraits, and no face-based search: a family navigates to their child’s proofs using the name registered on the school roster. Unconsented students appear in no gallery. The ordering interface presents the photographer’s package options — print packages, digital downloads, and any add-ons configured for the session. The proof gallery is built and production-ready, as is the ordering interface, on the platform’s commerce substrate. The payment rail is honest-off: it accepts no live family transactions today — present in the platform, not enabled for live payments. There is no live checkout and no billing active on the platform right now.

Gallery built · ordering interface built · payment honest-off

Photographer earnings and school fundraising leg — exact-cent split engine, charge rail honest-off

Every picture-day session on the platform carries three financial legs: the photographer’s earnings leg (the larger share), a school fundraising leg (a defined share of net proceeds flowing directly to the school), and the platform’s own take — the residual left after those legs, computed last, earned on the same orders, not skimmed off the top. The split engine divides proceeds with exact-cent precision: processing and lab costs come off gross proceeds first — the real, external costs of the sale — before any split is calculated. The photographer and school legs are each a share of the net that remains; the platform’s residual is simply what is left after those legs. A largest-remainder reconciliation pass ensures the total distributes to the exact cent, with no penny rounded silently in the platform’s favour and every leg — including the platform’s residual — visible in the breakdown. The photographer sees the projected distribution before the charge rail runs. The split engine is built and production-ready. The charge rail that moves money is honest-off: it exists in the platform but is not enabled for live transactions today.

Split engine built · charge rail honest-off

Yearbook export — PSPA/SPOA format, consent-audited, bulk metadata

At session close, the yearbook export produces every consented portrait in PSPA/SPOA format — the industry-standard delivery specification used by yearbook production vendors — alongside a bulk metadata file that maps each portrait to its roster entry: student name, grade, teacher, and class. Only students with a completed consent record appear in the export. The school or yearbook adviser receives an irrefutable consent audit log alongside the image files, so the yearbook goes to print with documented proof of consent for every student portrait included. The export also generates the red-flag summary: unmatched shots and missing students, so the yearbook adviser knows what to schedule for retakes. The export, consent-audit log, bulk metadata, and retake flag are built and production-ready. PNG-alpha cutout delivery alongside PSPA JPG is available where the school-choosable backgrounds engine is configured.

Built · PSPA/SPOA format · consent-audited

Print fulfillment — order substrate built, outside-lab routing in active development

The fulfillment substrate manages the order handoff from a family’s purchase to print production: order line-items, package configuration, print-size specs per item, and order status tracking per student. The order model and package configuration layer are built and production-ready on the platform’s commerce substrate. Outside-lab routing is in development: directing orders to a photographer’s preferred third-party print lab uses the PhotoLabProvider seam, which defines the interface, and active wire-up to named outside labs is in development. On-platform fulfillment routing is in active development alongside the payment rail. No live print orders are being routed today.

Order substrate built · lab routing in development

Who uses it

Built for the solo photographer, the school, and the parent — three distinct roles, one system

For photographers

You shoot picture day for a handful of schools a season. You want the whole job in one place: the consent list so you know who to photograph, the session cards so every portrait lands matched at upload, the red-flag summary so you know what to fix before you leave, and the PSPA/SPOA export so the yearbook handoff is a file, not a conversation. The photographer’s earnings leg is the larger share of every order. The school gets a fundraising leg from the same transaction. You do not need to run two separate financial conversations — the split engine handles both.

For schools

You coordinate picture day logistics and want the consent record to be airtight. The consent audit log goes with the yearbook export files — so every portrait in the yearbook has a documented consent record before the file ships. The school’s fundraising leg is a defined share of net order proceeds, flowing directly to the school from every family order. Student data is owned by the school from day one: exportable at any time, never shared with advertising networks, never public.

For parents

You opted in. You receive a link to your child’s private proof gallery — accessible by roster name, not by face scan. No other family’s child appears in your gallery. You choose from the photographer’s package options and place an order. You can withdraw consent at any time: the photo disappears from the gallery and from the yearbook export immediately. Your child’s portrait is never public and is never used for advertising or profiling.

How student photos are handled — plainly

Consent-gated. Access-controlled. No face match in the workflow. Revocable immediately.

Student portrait data is owned by the school and is never sold or shared with outside companies for profit. Every portrait is gated by parental consent: a family that did not opt in has no portrait in any gallery, no portrait in the ordering interface, and no portrait in the yearbook export. This is enforced at the data layer — code, not policy.

No facial recognition is used in the picture-day matching workflow. Portrait-to-student matching is done via QR code or barcode read at the moment of capture — a deterministic link, not a face comparison. Face-matching is off by default: any face-processing capability runs only under a separate, explicit per-family opt-in, never in the standard picture-day workflow, and any template it creates is kept only inside our own private infrastructure, with no outside recognition service connected. Withdrawing the opt-in stops the matching. The school’s retention window — 365 days by default — is what marks a template due for destruction; the step that destroys the stored template is not finished, and we will not tell a school it runs on a schedule when it does not. Face detection features — auto-grouping, auto-blur, smile detection — are off by default and are not part of the standard session. AI enhancement (skin smoothing, teeth whitening, beauty filters) is not applied to student portraits without an explicit per-family opt-in. This is a design choice enforced at the data layer, not a policy statement that could be changed silently.

Photos are retained for the session lifecycle (typically 60–90 days post-session). Consent revocation takes effect immediately: the portrait is removed from all galleries and excluded from all exports. The school can export every data record at any time. The platform architecture is FERPA-aware and COPPA-conscious; formal certification is in progress and will be stated when earned, not before.

What is built and what is coming — plainly

The picture-day engines are built. The payment rail is not live yet.

Built and production-ready today: the consent gate and pre-session consent collection; roster-driven session setup and QR/barcode student-to-photo matching; red-flag detection for unmatched shots and missing students; private per-student proof galleries on the commerce substrate; the split engine (photographer earnings leg, school fundraising leg, the platform’s residual computed last, exact-cent, costs-off-gross-first, largest-remainder reconciliation); PSPA/SPOA yearbook export, consent audit log, bulk metadata, and retake flag; the print fulfillment order model and package configuration layer.

Not yet enabled for live use: the payment rail (the part that processes family orders), live parent checkout, the charge rail that moves money through the split engine, and outside-lab routing to a photographer’s preferred third-party print lab. These are honest-off — present in the platform, not enabled for live transactions. There is no live checkout here, no billing, and no subscription. We say so directly because photographers booking schools for the coming season deserve to know what is production-ready and what is still being wired.

Connected to the school platform

photog.software shoots the day. homeroom.software publishes the book. Seen puts every student on a page.

photog.software handles the picture-day workflow: consent, capture, proofs, fulfillment, and yearbook export. homeroom.software is the school publishing platform: yearbook, newspaper, and newsletter from one editorial engine, with the same consent substrate the photo platform runs on. Seen is the recognition layer: the programme that ensures every student lands on a real page in the yearbook or the playbill — adviser-approved and consent-verified. For the studio running school photography at scale — multi-school branded stores, commission ledger, rep management — the sibling platform at photographer.software is the right fit.

homeroom.software seen.school photographer.software k12.photos

Early access · Solo photographers and small shops booking schools for the coming season

Book a conversation to see the current state honestly

photog.software is in active development. We do conversations that show the current state honestly: the consent collection and session setup workflow, how QR/barcode matching ties each portrait to its roster entry on upload, how red-flag detection surfaces unmatched shots and missing students, how the split engine models a photographer earnings and school fundraising distribution, and how the yearbook export produces PSPA/SPOA files with a consent audit log. There is no pricing commitment and no signup. If it looks right for your school season, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions

Does collecting consent before picture day actually save the photographer time?

Yes — and that is the frame the platform is built around. A pre-session consent list tells the photographer exactly who to photograph for the school record and who to skip. Shots of opted-out students do not need to be taken, sorted, or culled. Red-flag detection at session close flags unmatched shots and missing students before the photographer leaves the school, so retake decisions happen on-site rather than after a week of post-processing. Consent is not overhead here: it is the mechanism that makes the session run cleaner and the post-session work lighter.

How does the QR/barcode matching work?

Before picture day, the platform generates a session card for every student on the school roster. The card carries a QR code or barcode that ties back to that student’s roster entry — name, grade, teacher, class. The photographer scans or reads the code at capture; the portrait lands matched to its student from the moment of upload. Every match is an explicit, code-read-at-capture link — a QR/barcode read, not a face comparison or AI inference. (Any separate face-matching lane is off by default and opt-in only; when a parent enables it, the template is kept only in our own private infrastructure until consent is withdrawn or retention ends.) The QR/barcode matching system and roster management are built and production-ready.

What happens to photos of students whose families did not consent?

A student without a completed parental consent record does not appear in the shared proof gallery, the ordering interface, or the yearbook export — enforced at the data layer, not by a policy reminder. If the photographer captured a portrait of that student before checking the consent list, the platform excludes it from every downstream step automatically. Consent can also be withdrawn after the session: a revoked consent takes effect immediately and permanently — the photo is removed from any gallery where it appeared and excluded from any future export. No parental action beyond the revocation is required; the platform enforces it.

Is the payment for family photo orders enabled today?

No. The proof gallery and ordering interface are built on the platform’s commerce substrate. The payment rail that accepts live family transactions is honest-off: it exists in the platform but is not enabled for live orders today. There is no live checkout, no billing, and no subscription. When the payment rail is enabled (a founder-gated decision), the split engine will distribute the photographer’s earnings leg, the school’s fundraising leg, and the platform’s residual automatically. The CTA here is “book a conversation,” not “start an order.”

How does the split between my earnings and the school’s fundraising leg work?

Every session on the platform carries three financial legs. The photographer’s earnings leg is the larger share of the net. The school’s fundraising leg is a defined percentage of net proceeds flowing directly to the school — it does not come out of the photographer’s earnings share. The platform’s own take is the residual left after those two legs — earned on the same orders, computed last, not a fee skimmed off the top. The split engine deducts processing and lab costs from gross first (the real, external costs of the sale), applies the photographer and school legs to the net that remains, and runs a largest-remainder reconciliation pass so the distribution totals to the exact cent — with every leg, including the platform’s residual, visible in the breakdown. The split engine is built and production-ready. The charge rail that moves money is honest-off.

How long are student photos stored on the platform?

Photos are retained for the session lifecycle: from upload through the ordering window, typically 60–90 days post-session with the exact duration configured per session. After the ordering window closes, photos are not retained indefinitely by default. A family may archive their child’s proofs to their own private record before the session closes. Consent can be withdrawn at any time during the retention window; revocation is immediate and permanent — the photo is removed from all galleries and excluded from all exports. The school owns its roster and consent data from day one; that data is exportable at any time.

Does the platform use facial recognition to find or identify photos?

No. The platform does not use facial recognition to find or identify photos in the standard picture-day workflow. Portrait-to-student matching is done entirely via QR code or barcode read at the moment of capture — an explicit, deterministic link, not a face comparison or an AI inference. Face-matching, face scanning, face detection, and face-based search are off by default: any such capability runs only under a separate, explicit per-family opt-in and is never part of the standard session workflow. When a face lane runs under opt-in, it is permission-checked and kept only inside our own private infrastructure. Withdrawing consent, or the end of the retention schedule, is what marks the template due for destruction — and the step that actually destroys it is not finished, so we would rather say that plainly than claim a deletion we cannot show you. It is not used to match or identify students in this platform's picture-day flow.

What format does the yearbook export use?

The yearbook export produces portraits in PSPA/SPOA format — the industry-standard delivery specification used by yearbook production vendors. Each portrait is delivered as a JPG per the PSPA/SPOA spec. The export includes a bulk metadata file mapping each portrait to its roster entry: student name, grade, teacher, and class, in the column structure the production vendor expects. Only students with a completed consent record appear in the export. A consent audit log is included with the export files. PNG-alpha cutout delivery alongside PSPA JPG is available where the school-choosable backgrounds engine is configured.

How is photog.software different from photographer.software?

photog.software is built for the solo photographer or small shop — one person or a small team running school picture day for a handful of schools a season, keeping the whole job in one tool. photographer.software is built for the established studio running school photography at scale: multi-school branded stores, a per-school commission ledger for reps, and studio-wide operations on the same picture-day engine. Both run on the same underlying platform. The distinction is scope and audience: photog.software assumes the photographer is the sole operator; photographer.software assumes a studio with staff, reps, and a portfolio of school relationships.

What can a solo photographer actually use right now?

The platform is in active development. In a demo we walk through the current state honestly: consent collection and session setup, how QR/barcode matching ties each portrait to its roster entry on upload, how red-flag detection surfaces unmatched shots and missing students, how the split engine models a photographer earnings and school fundraising distribution, and how the yearbook export produces PSPA/SPOA files with a consent audit log. None of that involves live payments today. A conversation is the honest next step — we show what is built, what the payment-rail timeline looks like, and what early access means for your school season.