About · Schedule.software
We did not build a demo and describe what it could do. We built an operation and opened the engine.
Schedule.software is a product of Stanley Studios. It exists because we were already running the hardest version of this problem — school picture days, where a studio books hundreds of family sittings, dispatches its own crew across several buildings, and routes the day, all in the same week, against rosters full of children whose data is not ours to be casual with.
That is an unusual place to start a scheduling company, and it is the reason this product has the shape it does.
Why we entered in the middle
Every scheduling company owns one column. The middle of the board was empty.
Look at the scheduling market as a board with five columns: personal appointment links, business-services booking, room and resource management, workforce shifts, and field-service dispatch with routing. Almost every established product owns exactly one of those columns and treats the other four as someone else’s category. The calendar tools have no dispatch. The field-service tools are operator-only and ship no consumer booking page. The room-booking tools do not know what a shift is.
We did not spot that gap and rush to fill it. We arrived in it by accident, from underneath. Running picture-day operations means a family books a time on a public-facing page, a crew is dispatched to a building, a route is planned across the day, rooms are reserved, and staff shifts are covered — simultaneously, from one calendar, or the day does not work. Building that honestly meant building the hardest column first and discovering the other four were the same engine wearing different clothes.
The consequence is that we cannot easily be copied by adding a feature. A general calendar product can add a dispatch board; it cannot retrofit a data model in which a room, a person, a vehicle and a slot are the same kind of thing with the same exclusivity rule. The shape of the product is the argument, not the feature list.
How we know it works
The proof is not a case study. It is that we run on it.
We run our own K-12 scheduling operations on this exact engine. Not a fork of it, not a simplified internal version — the same booking primitive, the same availability model, the same database invariants. Real picture days, real conference calendars, real crew dispatch and route planning, real facilities bookings.
That arrangement has a cost we think is worth stating out loud: it means our own operations break first when something is wrong. A scheduling bug is not a support ticket from a stranger, it is a Saturday where a photographer is standing in the wrong gym. It has made us conservative in specific ways — correctness rules live in the database rather than in application code, because application code is where the plausible-looking race condition lives, and we have been on the wrong end of that particular Saturday.
It also means we do not have adoption numbers to quote at you, and we are not going to invent any. There are no customer logos on this site, no “trusted by N districts” band, and no testimonials, because a product this early that displays those has usually manufactured them. What we have instead is a working operation and a specific list of what is built.
The plain inventory — built, partial, planned, and off
What exists today, without the marketing tense
Software marketing has a habit of describing planned work in the present tense and letting the reader sort it out. The table below is the whole inventory in one place, and every page on this site is written to agree with it.
| Area | State today | What that means precisely |
|---|---|---|
| Booking surfaces (K-12 and studio) | Six in production, two module-dark | Listed individually on the surfaces page. Module-dark means built and finished, gated behind a module-enable flag rather than on by default. |
| Scheduling modules | Two built, four partial, one planned | Broken out on the modules page. Partial means the engine runs and the self-serve surface is still in development. |
| Booking correctness guarantees | Built and enforced at the database | A partial-unique index prevents a second live booking for the same student and event; per-slot capacity is counted under a lock in the transaction that books. |
| Reminders and notifications | Honest-off | The queueing and opt-in suppression logic is built. Nothing is being sent through this surface today. |
| Booking fees and payments | Honest-off | A fee is computed as a line and reserved in the ledger. No money moves, and there is no checkout anywhere on this site. |
| Self-serve sign-up | In development | Which is why getting started offers a conversation rather than a sign-up form that could not provision an account. |
| Route optimisation | Built, advisory | It proposes a route for a crew day. A human reviews and commits it; it does not dispatch anyone on its own. |
| Advisory master schedule | Built, module-dark, advisory | It proposes a timetable and explains what it could not place. Prerequisite and grade-eligibility gating is not wired and is not claimed. |
What we will not do with a school’s data
Some of this is policy. Most of it is that the data was never collected.
A scheduling product has a narrow appetite by construction, and we have tried hard not to widen it. It needs to know when a slot is open, who is entitled to take it, and whether taking it would break a rule. Most of what a district worries about handing to a vendor, a scheduler never needs to be given.
So: there is no facial recognition here, and the reason is not a policy commitment we could quietly revise — it is that this product holds no photographs. Picture day is scheduled here; the photographs live in the school-photography product that runs the shoot, under its own published policy, on its own site. There is no photo store, no gallery and nothing sold to a family. We do not build an advertising or behavioural profile from a booking, and scheduling data is not a product we sell or rent. There is no third-party analytics or advertising script on this site.
For minors specifically: scheduling data is consent-aware, access-controlled and never public. Identity fields on a roster route pass through a consent chokepoint at the server, so a suppressed student’s name is stripped rather than merely hidden from a view. The calendar feed carries no names at all. There is no roster to browse and no open sign-up sheet, and a cross-family request returns the same uniform 404 as a page that does not exist — so the surface cannot be used to test whether a given child is enrolled. And no automated decision is made about a child: the master schedule proposes, a human commits. The privacy page is the long version of this paragraph, holding by holding.
Who you would be dealing with
A small team that runs the operation it sells
✓Stanley Studios owns and builds it
Schedule.software is built and operated by Stanley Studios. It is one product in a group of vertically-integrated school products — picture day, publishing, fundraising — that share the same operational reality and the same posture about children’s data. There is no separate scheduling company, no acquired codebase and no white-label of someone else’s engine underneath.
✓One engine, not a fork per customer
An organisation running its own instance configures the modules relevant to its operation through the same owner-context discriminator that drives the education and field-service arms. No separate fork, no separate codebase. When a correctness fix lands, it lands everywhere at once.
✓Independent of the rest of the group
Schedule.software does not require any other product to be useful. It integrates with homeroom.software for schools that also run publishing, and with pictureday.software for studios, but neither is a prerequisite and neither is a parent product this one hangs off. It is a scheduling platform that happens to be built by people who run schools’ picture days.
✓You can talk to the people building it
There is no sales team to route around. The contact page has an address and no form — no lead capture, no scoring, no drip sequence. Early conversations are with the people who write the code, which is the only real advantage a small team has and we would rather not waste it.
If you want the technical version of why the booking guarantees hold, the how it works page walks the four-step flow, lets you work through the slot arithmetic yourself, and answers the six edge cases that actually decide whether a scheduler is worth running.