Yearbook Ltd · many programs, one platform
Run many yearbook programs on one platform.
A multi-school operator, a district, or a company running yearbooks for a portfolio of schools runs the same built platform every single program runs — one production editor, one picture-day-to-book pipeline, one proof gate, one press-ready export — each program off its own school roster. The scale is in the count of programs, not in a merged master database: each school’s data is walled from the next by per-school tenant isolation enforced at the data layer, so one program can never read another program’s records. A central account structure holds the portfolio as an explicit set of assignments. The money rails are honest-off across every program, so any portfolio view reflects built order and campaign data, not live transactions. We name that plainly.
This is the organization-scale door. The single-school, run-it-yourself door is schoolyearbook.software. The full product each program runs is at yearbook.software. Every school owns its own data; running many programs under one operator does not merge them.
What organization scale looks like
Scale here is the count of programs, not the merging of their data. Five surfaces below are built and running. The sixth — the live payment rails, portfolio-wide — is honest-off, and marked so.
Many programs, one toolchain
Every school in the portfolio runs the same built yearbook product — the multi-surface production editor (spread layout, layers, masking, typography, the ladder and cover surfaces), scoped staff roles, the adviser proof gate, automated pre-flight, press-ready PDF export, and the online edition. An operator is not maintaining a different tool per school; it is running one toolchain across many programs. The product is built and running. Shipped
Per-school tenant isolation
A record from one school is never visible to another school. 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. Running fifty programs under one operator does not merge fifty rosters into one; it runs fifty walled programs. The isolation is built and enforced. Shipped
One roster per school
Each program is built on its own school 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 programs; the operator holds many rosters, each owned by its school. The per-school roster model is built and running. Shipped
A central account structure
An operator holds the portfolio 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 someone’s memory. The portfolio is a set of real records, not a spreadsheet of school names. The account-structure model is built and running. Shipped
Portfolio visibility
An operator can see the state of its programs — which schools are assigned, where each program stands in its build, and the built order and campaign data per program — without breaking the wall between schools. Visibility is a roll-up of what each isolated program reports, not a shared pool that cross-reads student data. The per-program status surface is built; a live financial roll-up waits on the money rails. Shipped · live financial roll-up honest-off
The money rails, portfolio-wide
The order economics — scoped books, deadline windows, the four-way payout split — and the mission-giving campaign substrate are built into every program. What is not yet enabled, on any program, 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 portfolio. No card has been charged on any program here yet. We name that plainly. Early access — live payment rails
Standing up many programs
An operator builds a portfolio one program 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 operator is set up as an organization. A partner organization holds the portfolio, with members carrying account-manager roles distinct from any school’s staff. This is the structure the many programs 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 portfolio by the school-leaf isolation policy.
- Accounts are assigned within the portfolio. Each school account is assigned to the operator’s members, with a primary flag and effective-from / effective-until dates, so the portfolio is an explicit, time-bounded set of assignments rather than an informal list.
- Every program 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 many times.
- The operator watches the portfolio without breaking the wall. Portfolio visibility rolls up what each isolated program reports — assignment state, build progress, built order and campaign data — without any program cross-reading another’s student data. The wall holds while the operator still sees the whole picture.
- The money rails stay honest-off, everywhere. The order and giving economics are built into every program, but the live payment rails are honest-off across the whole portfolio. Any financial view reflects built data, not live transactions. The scale is real; the money has not moved yet.
Scale without merging the data
The hardest thing to get right at organization scale is keeping many schools’ data apart while one operator runs them all. The platform does it at the data layer, not by trusting every route to remember.
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 uphold; it is a policy the engine enforces.
Many rosters, never a master list
An operator with many programs holds many rosters — one per school, each owned by that school and imported once. There is no merged master roster across the portfolio. A student on one school’s roster is not on another school’s, and no operator-level view pools them into a single list. The portfolio is a set of walled programs, not one big database of children.
Roll-up without cross-read
Portfolio visibility is a roll-up of what each program reports, not a shared pool that reads across schools. An operator sees assignment state and build progress across programs; it does not get a query that reads one school’s student records from another school’s context. The whole-portfolio view is built from isolated reports, so seeing the whole picture never requires breaking the wall.
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 one 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.
One toolchain, run many times
An operator running many programs does not want many tools. The value at organization scale is that every program runs the identical built toolchain, so a practice that works for one program works for the next, and there is one product to learn rather than a patchwork.
Every program uses the same production editor, the same scoped-role model, the same picture-day-to-book pipeline, the same fail-closed proof gate, the same automated pre-flight, and the same press-ready export. A staff practice, a coverage-gap habit, or an approval workflow that an operator standardizes carries to every school in the portfolio, because there is nothing different to standardize against. The operator sets a way of working once and runs it many times.
The platform is free for the school to run at any scale — there is no per-school license, no per-student fee, and no volume contract for the software. An operator does not pay a growing software bill as the portfolio grows. When live selling is enabled, the platform is funded on the sale side, program by program, never by charging a school or an operator to use the software.
Print stays the operator’s choice. Each program exports a press-ready PDF to whichever lab it uses; there is no captive print vendor and no volume print agreement built into the software. An operator can standardize a lab across the portfolio or let each school keep its own — the software does not force either.
What a portfolio operator gets, and what it does not
Organization scale is a real posture on this platform, but it is honest about its edges. Here is what is built for a multi-program operator, and where the honest limits are.
Built: the portfolio as real records
An operator holds its portfolio as a partner organization with members and explicit, time-bounded account assignments across many schools. The build state of each program, its scoped staff, and its built order and campaign data are visible per program. This is real machinery, not a slide — the portfolio is a set of records the operator works against.
Honest-off: live financial roll-up
An operator cannot watch live revenue across the portfolio today, because the live payment rails are honest-off on every program. Any financial view reflects built order and campaign data, not charged cards. We do not present a live portfolio revenue dashboard, because no card has been charged on any program yet. The order economics are built; the money has not moved.
Phase two: enforced territory
For a partner-scale operator, territory machinery is phase two. Accounts are worked by explicit assignment, and a rep’s territory is a free-text note — there is no live or enforced territory, exclusivity, or geographic lead routing yet. An operator plans around account assignment, which is real, rather than a territory system that is not.
Built: isolation that holds at scale
The one thing that does not degrade as the portfolio grows is the wall between schools. Per-school tenant isolation is enforced at the data layer regardless of how many programs an operator runs. Adding the fiftieth program does not weaken the isolation on the first; each school stays a walled tenant no matter the count.
Common questions
Who is yearbook.ltd for?
An organization running many yearbook programs: a multi-school operator, a district, or a company that operates yearbooks for a portfolio of schools. It describes the same yearbook platform every single program runs, from the many-programs angle — one toolchain across many schools, each school a walled tenant.
If one operator runs many 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. Running many programs under one operator runs many walled programs; it does not merge their rosters or their records into a master database.
Does every program run the same tools?
Yes. Every school in the portfolio 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. An operator runs one product many times rather than maintaining a different tool per school.
Can an operator see revenue across all its programs?
Not as live revenue, because the live payment rails are honest-off on every program. An operator can see the built order and campaign data per program, but any financial view reflects built data, not charged cards. There is no live portfolio revenue dashboard, because no card has been charged on any program yet. We say so plainly.
How does an operator hold its portfolio of schools?
As a partner organization with members and explicit account assignments across many school accounts. Each assignment carries a primary flag and effective-from / effective-until dates, so the portfolio is a real, time-bounded set of records that can be handed off with history preserved — not an informal list of school names.
Do operators get protected territories?
Not today. Territory machinery is phase two. Accounts are worked by explicit assignment, and a rep’s territory is a free-text note — there is no live or enforced territory, exclusivity, or geographic lead routing yet. An operator should plan around account assignment, which exists, rather than a territory system that does not.
What does the software cost at scale?
The platform is free for the school to run at any scale — no per-school license, no per-student fee, and no volume software contract. An operator does not pay a growing software bill as the portfolio grows. When live selling is enabled, the platform is funded on the sale side, program by program, never by charging a school or operator to use the software.
Does isolation weaken as the portfolio grows?
No. Per-school tenant isolation is enforced at the data layer no matter how many programs an operator runs. Adding the fiftieth program 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-program configuration that could drift.
How is this different from the single-school door?
schoolyearbook.software is one program: a single school running its own yearbook, and a single roster. yearbook.ltd is the portfolio view: many such programs under one operator, held as an explicit account structure, each program still a walled tenant. Same platform, same per-program product; this page is the organization-scale posture over the top.
What is the honest next step for an operator?
A conversation. The many-programs machinery — the shared toolchain, per-school isolation, the central account structure, and per-program visibility — is built and real. The honest limits are that the money rails are honest-off across the portfolio and territory is phase two. 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 organization-scale door connects to the full product each program runs, the single-school counterpart, and the studio-side photography home. These destinations cover the adjacent surfaces.
yearbook.software
The umbrella product overview each program 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 program, one roster, no rep required. A single program in an organization-scale portfolio.
pholio.photos
The studio-side photography and proofing home. Each program’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 program in the portfolio runs.
What is built and what is honest-off
The shared toolchain every program 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 regardless of how many programs an operator runs. The central account structure — a partner organization with members and explicit, time-bounded account assignments across many schools — and one roster per school are built and running today. What is honest-off, across the whole portfolio, is the live payment rails: the sell checkout and the giving checkout are founder-gated and not enabled on any program, so any financial view reflects built order and campaign data, not charged cards — no card has been charged on any program here yet. Territory machinery for a partner-scale operator is phase two: accounts are worked by explicit assignment, with no live or enforced territory system. Each school owns its own data; running under one operator does not merge or transfer it. The platform is free for the school to run at any scale. 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.