Team photos your way — privacy built in, not added on

Granular consent means each family makes a separate decision for each use case — not one blanket signature. For a given student, a family can say yes to roster display, yes to prints, no to digital downloads, and no to yearbook inclusion; those four decisions are stored and enforced independently at the data layer. A proof approved for prints cannot be used for yearbook inclusion unless the family has also approved that use. Consent is time-stamped, auditable, and revocable at any time. The consent substrate that enforces this is built and production-ready; the family-facing dashboard that shows the audit log is in active development.

Not yet. The proof gallery and fulfillment pipeline are built and production-ready — the proof delivery, the per-item catalog, and the consent-gated ordering logic are all there. The charge rail that accepts payment from families is honest-off: it exists in the platform but is not enabled for live transactions today. There is no live checkout here. No billing. No subscription. When the ordering interface is enabled (a founder-gated decision), families and schools will be notified. The CTA here is “book a team shoot,” not “create an account and pay.”

Photos are stored on the platform’s own private infrastructure, encrypted in transit and at rest. They are never sent to outside advertising networks and are never sold to third parties. The one exception is print fulfillment: when a family places a print order, the approved photo is sent to a professional lab partner for printing. The fulfillment copy is used for printing and is not retained by the lab partner after the order ships. We do not claim photos never leave our infrastructure — that would not be accurate for a platform that fulfils print orders. What we do say, and what the architecture enforces: photos are never sent to an outside company unless a family has authorised a purchase, and they are never sold or shared for profit.

Photos are removed from the platform’s private infrastructure twelve months after the end of the season unless the family has chosen to archive before that date. This is encoded as a scheduled deletion in the data architecture — not a manual process dependent on someone remembering to act. Sixty days before the deadline, each family receives a reminder with the deletion date and a single-step archive option. Families who archive keep their photos; families who do not act see their child’s proofs deleted on schedule. The school retains yearbook-approved export files that were delivered before the deletion window. The twelve-month rule applies to proof galleries; printed orders that have already shipped are the family’s physical property.

No face biometric template is computed from a child’s photo in the shipping configuration. The consent and deletion machinery for face matching exists and is off by default per child; the matching capability behind it is not wired and cannot be switched on from this product. If a future feature uses face detection to help a family find photos of their child, that function will be family-initiated, logged, temporary, and deletable — and it will be off by default. Photos are never used to train AI models. AI-powered enhancement or restoration tools, if offered, would be family-initiated, applied to a copy of the proof (with the original kept), and logged. None of those features are enabled today; this answer describes the architecture constraints that govern if they are ever built.

An absent student is flagged in the shot list automatically because the QR roster scan at the line identifies who did not come through. A retake session is scheduled as a follow-on slot in the same shoot workflow: the student is assigned to the same roster record, the same consent architecture applies, and the same private gallery will receive the retake proof. When the retake proof is uploaded, it supersedes the original slot; if there was no original proof, the gallery populates for the first time from the retake. The retake management workflow is built and production-ready.

Yes, and revocation takes effect at the data layer immediately. A parent who revokes digital consent after the shoot triggers an immediate lock on that use for the affected proof; the photo becomes inaccessible for digital download without any manual cleanup step by an admin. The parent can see the updated consent audit log immediately. If a parent revokes all consent for a student, the proof is locked for every use — it is not automatically deleted from the platform’s private infrastructure (deletion requires a separate deletion request), but it cannot be used or displayed in any surface. Revocation cannot un-ship a print order that has already been fulfilled and shipped; for a physical print already in the family’s hands, the platform and the family discuss what resolution is appropriate.

A team composite is a group image that includes the full team roster. The composite layout engine draws from the imported roster and the approved proof set. A student whose depiction consent has not been granted is automatically excluded from the composite layout — their position is held but the proof is not placed, so the composite shows the rest of the team without that student. This is enforced at the layout engine, not by manual review. The excluded student’s family does not receive a composite that includes their child. If a parent later grants depiction consent and requests an updated composite, a revised layout can be generated. The composite layout engine is built and production-ready. The composite ordering checkout is honest-off — the same charge rail that is honest-off for all print orders.

The platform is in active development. In a conversation, we walk through the current state honestly: the team shoot scheduling and shot list workflow, the consent collection process, the private per-student gallery, and how the retake management and team composite layout work in practice. The ordering checkout — the interface that accepts payment from families — is honest-off. The early-access conversation is the honest next step: we show what is built, explain the checkout timeline, and discuss what a first team shoot looks like for your program. There is no pricing commitment and no signup.

Stanley Studios’ real photography team is South Carolina-based. For schools and teams in South Carolina, on-location team shoots are available. For schools and teams outside South Carolina, the platform’s consent management, private galleries, fulfillment pipeline, and data architecture are available with a remote upload workflow: your own photographer uploads proofs to the platform, and the platform handles the consent, the gallery delivery, the ordering workflow, and the fulfillment from there. We say “SC-based” honestly when describing our photography team — we do not imply a national on-location photography operation we have not built.