Yearbook City · the schools in your community, one platform
Yearbooks for the schools in your community.
A city, a district, or a local group serving the schools nearby runs the same built platform every school runs — one production editor, one picture-day-to-book pipeline, one adviser proof gate, one press-ready export — each school off its own roster. Running several neighbourhood schools under one local operator does not pool them into one database: each school’s data is walled from the next by per-school tenant isolation enforced at the data layer, so one school can never read another’s records. A central account structure holds the local set of programs as an explicit set of assignments, and the community can underwrite a book for a student down the street who cannot afford one. The money rails are honest-off across every school, so any community-wide view reflects built order and campaign data, not live transactions. We name that plainly.
This is the community door. A single school running its own book, on its own, is schoolyearbook.software. The organization-scale posture behind a local operator is yearbook.ltd. The full product each school runs is at yearbook.software. Every school owns its own data; serving many nearby schools does not merge them.
What a community program looks like
A community program is the count of nearby schools served, not the merging of their data. Five surfaces below are built and running. The sixth — the live payment rails, community-wide — is honest-off, and marked so.
Every local school, one toolchain
Each school in the community runs the identical built yearbook product — the multi-surface production editor (spread layout, layers, masking, typography, the ladder and cover surfaces), scoped staff roles, the picture-day-to-book pipeline, the adviser proof gate, automated pre-flight, press-ready PDF export, and the online edition. A local operator is not maintaining a different tool per school; it runs one toolchain across the neighbourhood. The product is built and running. Shipped
Neighbouring schools stay walled
A record from one school is never visible to another school, even when both sit under the same local operator. Isolation is enforced at the data layer with a school-leaf policy, not a WHERE clause an application route could omit — the policy fires before any application code reads a row. Serving a dozen nearby schools does not merge a dozen rosters into one; it runs a dozen walled programs. The isolation is built and enforced. Shipped
One roster per school
Each school is built on its own roster, imported once, and that roster is the spine of that school’s whole year — it drives the portrait flow, tags event photos, scopes the class books, and matches each book to a student at handout. There is no merged master list across the community; a local operator holds many rosters, each owned by its school. The per-school roster model is built and running. Shipped
A central account structure
A local operator holds the community’s programs as an explicit structure: a partner organization with members and account assignments across many school accounts, each assignment time-bounded and handed off deliberately rather than living in one person’s memory. The set of local schools is a real set of records, not a list of names on a whiteboard. The account-structure model is built and running. Shipped
Community books for students who cannot pay
The founding idea is that price never keeps a student out of the yearbook. A school sets a goal and a per-book amount, and the community underwrites books for local students who cannot afford one, tracked cent for cent from gift to distribution with an exact-cent no-skim ledger. The campaign substrate is built and running. The live giving checkout that moves a donor’s money is honest-off — no gift has been charged here yet. Shipped · live giving checkout honest-off
The money rails, community-wide
The order economics — scoped books, deadline windows, the four-way payout split — are built into every school. What is not yet enabled, on any school, is the live payment rail that charges a family’s card or moves a donor’s money. Those rails are honest-off across the whole community. No card has been charged on any school here yet. We name that plainly. Early access — live payment rails
Standing up the schools in a community
A local operator brings on the community’s schools one at a time on a shared toolchain. Each school is a walled tenant; the operator’s structure sits over the top of them, not inside them.
- The local operator is set up as an organization. A partner organization holds the community’s programs, with members carrying account-manager roles distinct from any school’s staff. This is the structure the nearby schools hang on.
- Each school comes on as its own tenant. A school joins with its own roster, imported once, and its own isolated data. From the first record, that school’s data is walled from every other school in the community by the school-leaf isolation policy.
- Accounts are assigned within the community. Each school account is assigned to the operator’s members, with a primary flag and effective-from / effective-until dates, so the local set of programs is an explicit, time-bounded set of assignments rather than an informal list.
- Every school runs the same toolchain. Each school builds its book in the same production editor, staffs it with scoped roles, pulls picture-day photos off its own roster, proofs through the fail-closed gate, and exports press-ready to the lab it chooses. One toolchain, run once per school.
- The community can underwrite books. A school sets a giving goal and a per-book amount, and the community funds books for local students who cannot afford one, tracked cent for cent on an exact-cent no-skim ledger. The campaign substrate is built; the live giving checkout is honest-off.
- The money rails stay honest-off, everywhere. The order and giving economics are built into every school, but the live payment rails are honest-off across the whole community. Any community-wide view reflects built data, not live transactions. The program is real; the money has not moved yet.
Local, without pooling the children
The point of a community program is that one local operator knows the schools nearby. The point of the data layer is that knowing them does not mean merging them.
A school-leaf isolation policy
Tenant isolation is enforced with a school-leaf policy at the data layer: a record is scoped to its school, and a session for one school reads nothing from another. The policy fires before any application code reads a row, so a route that forgot to filter still returns nothing across the wall. Isolation is not a convention a developer has to remember; it is a policy the engine enforces, no matter how many neighbourhood schools an operator serves.
Many rosters, never a community master list
A local operator holds many rosters — one per school, each owned by that school and imported once. There is no merged master roster across the community. A student on one school’s roster is not on another school’s, and no operator-level view pools the community’s children into a single list. The community program is a set of walled schools, not one big database of local students.
Local pride, on each school’s own terms
Every school in the community builds its own book, in its own voice, on its own ladder — the shared toolchain does not flatten a district into one template. A local operator can standardize a practice across schools if it wants, or let each school keep its own look. The platform runs the same either way; it does not force a house style on a neighbourhood.
Each school owns its data
Every school owns its students’ and families’ data. It is never sold to or shared with outside companies, and running under a local operator does not transfer ownership to the operator. Data involving minor students is consent-gated and can be withdrawn at any time, and minor student data runs on private systems and is never made public. Facial recognition is off by default and never auto-tags a child without an explicit per-child opt-in.
No student in the community left out
In a real community, some families can pay for a yearbook and some cannot. The mission-giving campaign is built so that a book still reaches the student whose family cannot — funded by the community, not skimmed by the software.
A school sets a campaign goal and a per-book amount. Local families, alumni, and businesses can put money toward books for students who cannot afford one. Every dollar is tracked cent for cent from gift to distribution on an exact-cent no-skim ledger, so the community can see that what was given became books, not overhead. The campaign substrate is built and running.
The live giving checkout that actually moves a donor’s money is honest-off — founder-gated and not enabled on any school. No gift has been charged here yet, and any campaign progress shown reflects built campaign data, not live donations. We say so plainly rather than presenting a live donation total.
This is a for-profit product. The giving campaign is not a charitable fund and no tax-deductible, charitable-deduction, or tax-receipt claim is made anywhere on this platform. The community underwrites books for local students; that is described as exactly what it is.
What a local operator gets, and what it does not
A community program is a real posture on this platform, but it is honest about its edges. Here is what is built for a local operator, and where the honest limits are.
Built: the community as real records
A local operator holds the community’s programs as a partner organization with members and explicit, time-bounded account assignments across many schools. The build state of each school, its scoped staff, and its built order and campaign data are visible per school. This is real machinery, not a slide — the community program is a set of records the operator works against.
Honest-off: a live community revenue view
A local operator cannot watch live revenue across the community today, because the live payment rails are honest-off on every school. Any financial view reflects built order and campaign data, not charged cards. We do not present a live community revenue dashboard, because no card has been charged on any school yet. The order economics are built; the money has not moved.
Free for every school to run
The platform is free for the school to run — no per-school license, no per-student fee, and no volume contract for the software. A local operator does not pay a growing software bill as it brings on more neighbourhood schools. When live selling is enabled, the platform is funded on the sale side, school by school, never by charging a school or a community to use the software.
Built: isolation that holds across the community
The one thing that does not degrade as the community program grows is the wall between schools. Per-school tenant isolation is enforced at the data layer regardless of how many nearby schools an operator serves. Adding the twelfth school does not weaken the isolation on the first; each school stays a walled tenant no matter the count.
Common questions
Who is yearbook.city for?
A city, a district, or a local group running yearbooks for the schools in one community. It describes the same yearbook platform every school runs, from the community angle — nearby schools on one toolchain, each school a walled tenant, held by a local operator as an explicit account structure.
If one local operator runs several nearby schools, is the data merged?
No. Per-school tenant isolation is enforced at the data layer with a school-leaf policy: a record from one school is never visible to another, and the policy fires before any application code reads a row. Serving many neighbourhood schools runs many walled programs; it does not merge their rosters or their records into a community master database.
Does every school in the community run the same tools?
Yes. Every school runs the identical built toolchain — the production editor, scoped staff roles, the picture-day-to-book pipeline, the adviser proof gate, automated pre-flight, press-ready export, and the online edition — off its own roster. A local operator runs one product many times rather than maintaining a different tool per school.
Can the community fund books for students who cannot afford one?
Yes, as built campaign machinery: a school sets a goal and a per-book amount, and the community can underwrite books for local students who cannot afford one, tracked cent for cent on an exact-cent no-skim ledger. The campaign substrate is built and running. The live giving checkout that moves a donor’s money is honest-off, so no gift has been charged here yet.
Is the giving campaign tax-deductible?
No. This is a for-profit product, and the giving campaign is not a charitable fund. No tax-deductible, charitable-deduction, or tax-receipt claim is made anywhere on this platform. The community underwrites books for local students; it is described as exactly that, and nothing more.
Can a local operator see revenue across all its schools?
Not as live revenue, because the live payment rails are honest-off on every school. An operator can see the built order and campaign data per school, but any financial view reflects built data, not charged cards. There is no live community revenue dashboard, because no card has been charged on any school yet. We say so plainly.
What does the software cost the community?
The platform is free for the school to run — no per-school license, no per-student fee, and no volume software contract. A local operator does not pay a growing software bill as it brings on more schools. When live selling is enabled, the platform is funded on the sale side, school by school, never by charging a school or a community to use the software.
Does isolation weaken as the community program grows?
No. Per-school tenant isolation is enforced at the data layer no matter how many nearby schools an operator serves. Adding the twelfth school does not weaken the wall on the first; each school stays a walled tenant regardless of the count. The isolation is a data-layer policy, not a per-school configuration that could drift.
How is this different from the single-school door?
schoolyearbook.software is one school running its own yearbook on its own, with one roster and no rep required. yearbook.city is the community view: several nearby schools under one local operator, held as an explicit account structure, each school still a walled tenant. Same platform, same per-school product; this page is the community posture over the top.
What is the honest next step for a community?
A conversation. The community machinery — the shared toolchain, per-school isolation, the central account structure, and the giving campaign — is built and real. The honest limit is that the money rails are honest-off across every school. A demo shows the current state plainly, including exactly what is not yet enabled. There is no pricing commitment and no signup.
Related surfaces
The community door connects to the organization-scale posture behind it, the full product each school runs, the single-school counterpart, and the studio-side photography home. These destinations cover the adjacent surfaces.
yearbook.ltd
The organization-scale posture behind a local operator: many schools on one platform, per-school tenant isolation, and a central account structure over the portfolio.
yearbook.software
The umbrella product overview each school runs: the whole yearbook arc — write, design, photograph, proof, print, sell, give, read — on one platform and one roster per school.
schoolyearbook.software
The single-school, run-it-yourself door: one school, one roster, no rep required. A single school in a community program.
pholio.photos
The studio-side photography and proofing home. Each school’s picture-day portraits flow from here into that school’s book.
homeroom.software
The flagship platform brand home: the full platform story behind the yearbook product every school in the community runs.
What is built and what is honest-off
The shared toolchain every school runs — the production editor, scoped staff roles, the picture-day-to-book pipeline, the adviser proof gate, press-ready export, and the online edition — is built and running today. Per-school tenant isolation, enforced at the data layer with a school-leaf policy so one school’s records are never visible to another, is built and enforced, and it holds no matter how many neighbourhood schools a local operator serves. The central account structure — a partner organization with members and explicit, time-bounded account assignments across many schools — one roster per school, and the mission-giving campaign substrate with its exact-cent no-skim ledger are built and running today. What is honest-off, across the whole community, is the live payment rails: the sell checkout and the giving checkout are founder-gated and not enabled on any school, so any financial or campaign view reflects built order and campaign data, not charged cards — no card has been charged on any school here yet. Each school owns its own data; serving many nearby schools does not merge or transfer it. The platform is free for the school to run. This is a for-profit product; no tax-deductible or charitable claim is made anywhere. No competitor brand names appear here. Pricing and checkout are not on this page.