Yearbook.software · The whole platform · Early access · 2026

The whole school yearbook, on one platform.

Write it, design it, photograph it, proof it, print it, sell it, give it, and read it — one platform, off one school roster. Each stage hands off to the sub-site that goes deep on it, so this page is the overview, not a repeat of any one of them. The engines are built; the two money rails — the sell checkout and the giving checkout — are honest-off, and no card is charged today.

See the whole platform How a year runs

One roster, end to endthe same roster drives portraits, tagging, order scope, sell-through, and the distribution check-in

8 stages, one platformwrite · design · photograph · proof · print · sell · give · read

Free for the school to runno subscription, no per-student fee; the platform is funded on the sale side, never by charging the school

Money rails honest-offevery engine is built; live sell and giving checkout are not yet enabled — no card is charged today

The whole platform

Eight stages, one connected platform

This is the umbrella. It summarises each stage and hands off to the sub-site that goes deep — it does not re-explain the storefront, the giving flow, or the production editor. Every engine below is built; the parts that move money are honest-off.

Stage 1 · Write

Write the stories — a real newsroom, not a blank page in April

Coverage runs through an editorial workflow all year: a story moves from pitched to assigned to reporting to drafting to copy-edit to design to editor-in-chief sign-off to adviser review to published. Staff roles are scoped at the data layer, so a section editor cannot overwrite another section. The reporting a staff builds through the year feeds the book’s news pages at deadline — and a live news site in parallel — instead of being reconstructed from memory in the final week. The newsroom lifecycle engine is built and production-ready.

Built · goes deep at yearbook.news

Goes deep at yearbook.news — the newsroom editorial workflow that fills the book’s stories.

Stage 2 · Design

Design the book — a production editor, not a consumer photo-book wizard

The book is built on a multi-surface production editor: spread layout, layers, masking, typographic control, and the structural surfaces a real yearbook needs — the ladder that plans every page, the table of contents, the endsheets, and the cover. It runs on a resilient online workspace, so many editors work in parallel without overwriting each other and no crashed lab computer loses a spread. Photography is treated as the primary design material, not a clip-art accent. The production editor is built and live.

Built · goes deep at yearbook.press

Goes deep at yearbook.press — the press-grade production editor (layers, masking, typography).

Stage 3 · Photograph

Photograph the year — every event feeds the right spread

Photos come in from every event of the year — picture day, games, dances, concerts, club inductions, senior moments — and are tagged to the right student off the school roster. A coverage-gap report shows, before deadline, which students and groups are not yet on a spread. Facial recognition is off by default and is never used to auto-tag a photo unless a parent explicitly enables it for their own child. The event-capture, roster-tagging, and coverage-gap engines are built and production-ready.

Built · goes deep at yearbook.events

Goes deep at yearbook.events — season-long coverage and distribution-day check-in.

Stage 4 · Proof

Proof and approve — a fail-closed gate, and a link, not a giant file

An adviser reviews the book spread by spread, leaves comments, locks a version, and approves through a fail-closed approval gate — nothing advances to print until it is genuinely signed off. A read-only proof link reaches the principal or the print lab without generating and emailing a giant file. The proof-approval workflow and the no-file proof link are built and live.

Built · goes deep at yearbook.press

Goes deep at yearbook.press — the adviser proof-approval gate and version locking.

Stage 5 · Print

Print to a press standard — and pick your own lab

At deadline the platform runs an automated pre-flight file check — resolution, bleed, colour — and exports a press-ready PDF the school can send to whichever print lab it uses. Delivery status is tracked from proof to print run to fulfillment. The book does not have to be “adjusted to survive” a consumer export. The pre-flight, press-ready export, and delivery-tracking engines are built and production-ready. The print-order checkout that takes a family’s payment is honest-off — present in the platform, not enabled for live transactions.

Built · print checkout honest-off · deep at yearbook.press

Goes deep at yearbook.press — pre-flight, press-ready PDF export, and delivery tracking.

Stage 6 · Sell

Sell the book — server-priced, so what a family sees is what bills

When it is time to sell, the order rails resolve every unit price server-side from the school’s catalog — the buyer never types in the amount. A school can sell a whole-school book, a grade book, a single class book, or a club book, run an early-bird-to-deadline price schedule, and every sale splits four ways (studio, photographer, school, platform) with an optional fundraiser cut from the school’s own share. The order, pricing-window, scoped-book, and payout engines are built and production-ready. The live payment rail is honest-off; a family reserves a copy today. This umbrella does not re-explain the storefront — yearbook.sale is the storefront, and yearbook.marketing reminds only the families who have not ordered.

Built · live checkout honest-off · deep at yearbook.sale

Goes deep at yearbook.sale — the direct-sales storefront and reserve flow.

Stage 7 · Give

Give a book to a student who cannot afford one — price never keeps a student out

The founding idea of the whole program is that every student deserves a yearbook. A school sets a goal and a per-book amount, and the community underwrites books for students who cannot afford one, tracked cent for cent in plain view from gift to distribution with an exact-cent no-skim ledger. This umbrella does not re-explain the giving flow — yearbook.fund is the mission-giving surface, and it goes deep on the campaign and the ledger. The campaign substrate is built; the live giving checkout that moves a donor’s money is honest-off.

Built · live giving checkout honest-off · deep at yearbook.fund

Goes deep at yearbook.fund — the mission-giving campaign and the no-skim ledger.

Stage 8 · Read

Read it, keep it, never lose it — the online edition and the always-safe workspace

The book lives online from the first spread to the final export. Every change autosaves as it happens, so a dead lab computer in April loses nothing. Presence shows who is in which section, and a section assignment gate at the data layer stops two editors overwriting each other. Any saved state of a spread is recoverable, so a staff can experiment and roll back. The autosave, presence-aware parallel editing, assignment gate, and version-recovery engines are built and live.

Built · goes deep at yearbook.cloud

Goes deep at yearbook.cloud — the resilient online workspace and archive.

How a year runs

A yearbook year, in four movements

One roster imported once, a book built all year in one workspace, then sold, given, and printed — each handing off to its sub-site. Every step is described as it is built today.

Step 1 · One roster, imported once

The school’s roster is imported a single time and becomes the spine of the whole year. The same roster drives the portrait flow, tags event photos to the right student, scopes a class book, targets the families who have not ordered, and matches each book to a student at handout. One import, not five. The platform is free for the school to run — there is no per-student fee and no subscription.

Step 2 · Build it all year, in one place

Stories are reported through the newsroom, spreads are designed in the production editor, photos are captured from every event and tagged off the roster, and the adviser proofs and approves through a fail-closed gate — all in one resilient online workspace where every change autosaves and many editors work in parallel without overwriting each other. Nothing is reconstructed from memory in the final week.

Step 3 · Sell, give, and print — each stage hands off to its sub-site

At deadline the book is pre-flighted and exported press-ready to the lab the school chooses; the storefront sells copies at a server-resolved price; and the community can underwrite a book for a student who cannot afford one. Each of these goes deep on its own sub-site — the storefront on yearbook.sale, the giving on yearbook.fund, the production and print on yearbook.press. The engines are built; both money rails (the sell checkout and the giving checkout) are honest-off, so no card is charged today.

Step 4 · Read it, keep it, own the data

The finished book lives as an online edition and an archive that does not vanish when a lab computer dies. Student and family data is owned by the school and is never sold to or shared with outside companies. Data that involves minor students is consent-gated and never made public; facial recognition is off by default. Consent can be withdrawn at any time.

The yearbook suite

Each stage has a sub-site that goes deep — this page just points the way

Make the book

yearbook.press is the press-grade production editor and print export. yearbook.cloud is the resilient online workspace where the staff builds it. yearbook.news is the newsroom that reports the stories. yearbook.events covers the year and runs distribution day.

Fund the book

yearbook.sale is the direct-sales storefront — server-priced, scoped class books, a four-way payout split. yearbook.marketing reminds only the families who have not ordered. yearbook.fund underwrites a book for a student who cannot afford one. This umbrella points to each; it does not repeat the storefront or the giving flow. Every money rail is honest-off — no card is charged today.

Teach the book

yearbook.education runs the program as a graded class — student roles with scoped access, coverage accountability, and a skills record a student can carry to a resume. Every one of these sub-sites is built on the same platform and the same roster as the rest of the suite.

To book a walkthrough: [email protected].

What is built and what is live — plainly

The engines are built. The two money rails are not yet enabled.

Built and production-ready today: the newsroom editorial workflow; the multi-surface production editor (layers, masking, typography, the ladder and cover surfaces); event capture and roster-driven photo tagging with facial recognition off by default; the adviser proof-approval gate and the no-file proof link; automated pre-flight and press-ready PDF export with delivery tracking; the server-priced order rails (scoped class books, deadline windows, four-way payout split); the mission-giving campaign substrate with an exact-cent no-skim ledger; and the resilient online workspace (per-edit autosave, presence-aware parallel editing, the section assignment gate, version recovery).

Not yet enabled for live use: the two money rails — the live sell checkout that charges a family’s card, and the live giving checkout that moves a donor’s money. These are honest-off: present in the platform, not enabled for live transactions. There is no live checkout here. No billing. No subscription. No school has run a live sale or a live gift on yearbook.software yet. A walkthrough that shows the current state honestly is the next step.

Early access · Advisers, administrators, and districts · See the whole program honestly

Book a walkthrough of the whole platform

Yearbook.software is in active development. No school has run a live sale or a live gift here yet. A walkthrough shows the current state honestly: how one roster drives every stage, how the production editor and the proof gate work, how the storefront and the giving campaign are configured, and exactly where the money rails are honest-off. There is no pricing commitment and no signup. If it looks right for your program, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions

What is this, exactly — and how is it different from the yearbook.* sub-sites?

This is the umbrella front-door for the yearbook program: the whole arc — write, design, photograph, proof, print, sell, give, read — on one platform, off one school roster. Each stage has a sub-site that goes deep on it: yearbook.press for the production editor and print, yearbook.sale for the storefront, yearbook.fund for mission-giving, yearbook.marketing for sell-through reminders, yearbook.cloud for the online workspace, and yearbook.events for coverage and distribution. This page summarises and hands off; it does not repeat what each sub-site explains in full.

Do I have to use the whole platform to use any of it?

No. Each stage stands on its own, and each sub-site can be used without the others. A school can run only the storefront, only the giving campaign, or only the production editor. The value of the whole platform is that the stages share one roster and one book — the portrait flow, the order scope, the sell-through targeting, and the distribution check-in all key off the same roster — but you are never required to adopt all of it at once.

Can a family buy a book here today? Is checkout live?

Not yet. Every engine described here — ordering, pricing windows, scoped class books, the payout split, the giving campaign — is built and production-ready. The parts that move money, the live sell checkout and the live giving checkout, are honest-off: present in the platform but not enabled for live transactions. There is no live checkout, no billing, and no subscription. No school has run a live sale or a live gift here yet. A conversation is the honest next step.

What does the platform cost a school?

The platform is free for the school to run. There is no subscription, no per-student fee, and no setup charge. When live selling is enabled, the platform is funded on the sale side — a small per-sale share of a printed-copy purchase — never by charging the school to use the software. Standing up the program costs the school nothing.

Where do I go to actually sell the book?

The storefront lives on yearbook.sale: a family reserves a copy at a price resolved server-side (what you see is what bills), can buy a scoped class book, and the sale splits four ways with an optional fundraiser cut from the school’s own share. To reach only the families who have not yet ordered, yearbook.marketing is the sell-through reminder engine. This umbrella does not repeat the storefront mechanics — it points you to them.

Where do I go to make sure no student is left without a book?

That is yearbook.fund, the mission-giving surface: a school sets a goal and a per-book amount, the community underwrites books for students who cannot afford one, and every dollar is tracked cent for cent from gift to distribution. This is a for-profit product and this page makes no tax claim of any kind; the fund surface goes deep on the giving flow. The campaign substrate is built; the live giving checkout is honest-off.

Where do I go for the production editor and to get the book printed?

That is yearbook.press: the press-grade production editor (layers, masking, typography, the ladder and cover surfaces), the adviser proof-approval gate, automated pre-flight, and a press-ready PDF export the school sends to the print lab it chooses. The school is free to pick its own lab. The production and export engines are built; the print-order checkout is honest-off.

How is this different from just using each sub-site on its own?

The sub-sites are the deep dive on one stage each. This umbrella is the connective story that none of them tells alone: one roster and one book carried end to end, so a photo tagged at an event in October is the same student on the class book scope in March and the same name on the check-in list at distribution. If you only need one stage, use its sub-site. If you are evaluating the program as a whole, this is the overview.

How is student and family data handled?

Student and family data is owned by the school and is never sold to or shared with outside companies, advertisers, or third parties. Data that involves minor students is consent-gated: a family opts in before their contact is used, and consent can be withdrawn at any time. Minor student data runs on our own private systems and is never made public. Facial recognition is off by default and is never used to auto-tag a photo without an explicit per-child opt-in from that child’s parent.

Can we run yearbook as a class or a newsroom?

Yes. yearbook.education runs the program as a graded class — student roles with scoped access, coverage accountability, an adviser feedback loop, and a skills record a student can carry to a resume. yearbook.news runs the newsroom side — the editorial workflow that produces the reporting and feeds both the book and a live news site. Both are built on the same platform and the same roster.