Photo Studio Software · for portrait, family, senior, and commercial studios
The studio operating system built for any photography business — not just school programs.
Running a photography studio means juggling booking, client communication, contracts, galleries, proofing, and order fulfillment at the same time. Photo Studio Software brings those pieces onto one substrate: scheduling and booking on the same slot engine that powers eight K–12 booking surfaces, consent-railed client galleries with built-in proofing, and one agreements engine that handles your contracts and client releases from a single place. The storefront is wired and in early access; we say so rather than presenting it as live today.
Built for portrait studios, family-photography businesses, senior photographers, commercial studios, and any hybrid. If your studio also runs school picture day, the school-program operator tooling is at schoolphoto.studio — a different product, cross-linked below. The storefront and payout rail are early access; the booking engine, galleries, proofing, and agreements engine are built today.
What is built and what is in early access
The four pillars below are the core of the studio operating system. The first three are built and running today. The storefront is early access: the infrastructure is wired, and money movement is switched off until enabled. We mark each honestly.
Scheduling and booking on the shared slot engine
Booking for a portrait studio is not a simple calendar event. A session has a time slot, a location, a session type, and a client — and overbooking a slot or double-booking a photographer is a real operational problem. The scheduling core is a single canonical slot-and-availability engine built across eight K–12 booking surfaces. Photo Studio Software uses that same engine with fixed-slot session mode: each session is a distinct slot with its own identity, capacity, and availability state. The studio defines the session types, the duration, the buffer between sessions, and the available windows; the engine handles the rest. Shipped
Consent-railed client galleries with proofing
Client galleries are permission-gated and tenant-isolated: a client sees only the photos from their own session, not another client’s. The consent rail means photos are not viewable outside the proofing step until the client has completed their session review. Proofing is structured: the client reviews each image, flags selects and passes, and the selections flow directly into the order or the delivery. The gallery system is the same one that backs school picture-day consent-gated parent galleries — applied here to the general-studio context. Shipped
One agreements engine for contracts and releases
A photography studio uses agreements at multiple points: a session contract before the shoot, a model release covering usage rights for an image, a print release if the client is taking files to a third-party lab, and potentially a commercial usage agreement for a business client. The shared agreements engine handles all of them from a single interface: the studio defines the agreement templates, the engine routes them to the correct signing party at the correct point in the workflow, and each signed record is stored against the session it covers. Shipped
Storefront and revenue rail
The storefront is the layer where a client places a print or product order from their proofed gallery. The order engine, the catalog structure, and the revenue ledger are wired. The actual payment processing and payout rail — the mechanism that moves money from the client to the studio — is switched off pending the founder enabling it. No transaction is processed today. We name this plainly: the storefront is early access, not live. Early access
How the pieces work together
A studio session follows a clear lifecycle from booking to delivery. Photo Studio Software covers each step on one connected substrate rather than requiring a separate tool for each:
- Booking opens. The studio publishes available session windows on the slot engine. A client books a specific slot — a fixed-identity appointment, not a floating request on a calendar. The engine tracks capacity, respects buffers between sessions, and prevents double-booking. The booking is tied to the client record and the session type from the moment it is created.
- Agreements are sent before the session. When a booking is confirmed, the agreements engine routes the relevant contract to the client. For a family portrait session that might be a session agreement and a print release. For a commercial client it might include a usage-rights agreement. The client signs digitally; the signed record is stored against the session.
- The session happens. The shoot runs outside the platform. What comes back is the set of images from the session, uploaded into the client’s tenant-isolated gallery. No other client’s gallery is accessible from the same view.
- Proofing runs in the consent-railed gallery. The client is notified that their gallery is ready. They enter through the gallery link, review the images in a structured proofing flow, flag selects, and complete their review. The studio sees the client’s selections in real time. No image is available for order or delivery until the proofing step is complete.
- The order flows from the proofed selections. When proofing is done, the client’s selections flow into the order. The storefront presents the available print products and digital options. Order fulfillment and the revenue rail are early access; the order data is captured and the flow is built, with payment processing switched off pending enablement.
- Delivery and the session record close. Delivered images, signed agreements, and order records are all stored against the session. The studio has a complete record for every client without assembling it from separate systems.
Built for any studio type, not a single specialty
The substrate is general by design. The booking engine, galleries, proofing, and agreements engine are not built around one session type — they are built around the common structure that any photography session shares. A few examples of how different studio types use the same pieces:
Portrait studio
A portrait studio books fixed-slot sessions (head shots, family portraits, individual sittings), sends a session contract through the agreements engine, runs gallery proofing after the shoot, and routes the client to the storefront for print orders. The slot engine handles the studio’s daily schedule across multiple photographers and multiple session types from the same interface.
Senior photographer
A senior photographer often runs multi-location outdoor sessions in addition to studio sittings. The slot engine handles both — a fixed outdoor-session slot is the same object as a studio appointment. The agreements engine routes a model release alongside the session contract. Proofing is where the senior client chooses their yearbook submission alongside their personal order. The school-submission workflow for yearbook photos lives at a different product (schoolphoto.studio); this page is the general-studio surface.
Family photographer
A family photographer working outdoors or on location books sessions with variable lead times and seasonal availability. The slot engine supports configurable availability windows and session durations. Gallery proofing after a family shoot is where the family reviews and selects; the consent rail keeps one family’s photos walled away from another’s. Print and digital orders flow from the proofed selections through the storefront (early access).
Commercial studio
A commercial studio needs the agreements engine most. A product shoot or a campaign requires a usage-rights agreement, sometimes a location release, and often a multi-party sign-off. The agreements engine handles the routing and storage. Gallery access for a commercial client is permission-gated the same way as a consumer gallery: the client sees only their session, and proofing produces a structured selects record the studio can take to post-production without a separate email thread.
One agreements engine, across every studio workflow
A photography business uses more legal agreements per transaction than most service businesses. Before the session: a contract covering scope, deliverables, cancellation policy, and payment terms. During or after the session: a model release covering how the images can be used — by the studio for portfolio work, by the client for personal or commercial purposes. If the client is taking digital files: a print release that specifies what they are licensed to do with them. If the client is a business: a commercial usage agreement covering the specific campaign or application.
Most studios manage this with a mix of PDF forms sent over email, DocuSign accounts, and paper releases signed at the shoot. The agreements engine consolidates that into one workflow: the studio defines the agreement templates, the engine routes them to the correct party at the correct point in the session lifecycle, the party signs digitally, and the signed record is stored against the session. The studio has a complete agreements file for every session without assembling it from inboxes and scanner apps.
The agreements engine is the same engine used across the platform for school contracts, school-photo operator agreements, and studio onboarding documents. It is not a separate integration or a third-party service embedded behind an iframe — it is one system, storing all agreement records in the same place as the session records they belong to.
Scheduling built on the slot engine — not a calendar plugin
Most booking tools for small studios are built on a calendar metaphor: a client picks an open time and the studio confirms it. That works until the studio has multiple photographers, multiple session types with different durations and buffers, and different availability by location or by day of week. The slot engine uses a different model: a session slot is a distinct object with its own identity, its own capacity, and its own availability state — not just an open block on a calendar grid.
Fixed-slot session identity
A slot is a specific booking opportunity — Tuesday the 15th at 10:00 AM for a 60-minute family portrait session — not a floating open window. When a client books that slot, it is claimed. When the session is complete, the slot is closed. The slot identity persists through the booking, the session, and the delivery record — so every agreement, every image, and every order can be found by the slot it came from.
Buffer and capacity rules per session type
A head-shot session and a full family portrait session have different durations and different buffer requirements between them. The slot engine lets the studio define those rules per session type: minimum duration, pre-session buffer (setup time), post-session buffer (client transition and cleanup). Scheduling a second head-shot session back-to-back with a family portrait session that needs a longer buffer is automatically blocked — the studio does not have to manage it manually.
Multi-photographer availability
A studio with more than one photographer on staff can define availability windows per photographer. The slot engine assigns a specific photographer to a specific slot at booking time, respects their individual availability, and prevents double-booking across staff members. A client who requests a specific photographer gets that photographer’s actual available windows, not the studio’s general calendar.
The same engine across eight booking surfaces
The slot engine is built on schedule.software and powers all eight K–12 booking surfaces on the platform: picture-day appointment windows, senior session slots, conference scheduling, and more. Photo Studio Software uses that same engine — not a separate booking system. A studio that also runs school picture days works on one scheduling substrate rather than juggling two separate tools. The school-program operator surface is at schoolphoto.studio; the general-studio surface is here.
Galleries and proofing that keep client work private
Client gallery access is one of the areas where photography software tends to create friction: the studio sends a link, the link is too public or too cumbersome, the client cannot easily flag selects, and the studio ends up with a thread of reply-all emails tallying the choices. The consent-railed gallery system is built to avoid each of those problems.
Galleries are tenant-isolated: a client sees only the images from their own session. The isolation is enforced at the data layer, not by an obscure link or a password that the client could share. A session gallery link resolves only for the account it was issued to. No other studio client can access it.
The consent rail means images are not accessible outside the proofing flow until the client has completed their review. The studio does not have to choose between “give the client a download link immediately” and “hold everything until they respond to an email.” The proofing step is the release point: the client enters the gallery, reviews each image in a structured flow, flags their selects, and submits. The studio sees the selections in real time and can proceed to delivery or order fulfillment from that record directly.
The gallery and proofing system is the same system used for school picture-day parent galleries — where the consent model is particularly strict, because minors’ images are involved. Applied to the general studio context, the same structural guarantees mean a commercial client’s unpublished campaign images are walled away from any other session with the same rigor as a school’s student portraits.
What is in progress and what is planned
These capabilities are not presented as available today. They are named so a studio considering this platform can see the direction and the honest state of each item — rather than discovering gaps after committing.
Storefront payment processing
The storefront order engine, the product catalog, and the revenue ledger are wired. The payment processing and payout rail — the mechanism that moves money from a client to the studio — is switched off pending founder enablement. When it is turned on, the studio will be able to accept client orders for prints and digital products directly through the proofed gallery. No transaction is processed today, and we say so plainly. Early access
Client-facing booking portal
The slot engine and the studio-side booking management are built. The client-facing booking portal — the public page where a client can see available session windows and request a booking directly — is in active development. Today a studio manages bookings through the admin interface; the client-facing self-booking surface is the next step. In progress
Product catalog builder for print and digital
The studio will be able to define its own print product catalog — sizes, finishes, products, digital download tiers — which populates the storefront at the order step. The catalog builder and the storefront product display are planned alongside the storefront payment enablement. Planned
Automated session follow-up and delivery
After a session is complete and proofing is done, the studio needs to communicate with the client about their order status and delivery timeline. An automated follow-up path — triggered by proofing completion or order placement, routed through the consented contact record — is planned as part of the agreements and communication layer. Planned
Multi-location studio management
A studio that operates across more than one physical location needs the slot engine to handle location-specific availability windows and photographer assignments per location. The data model supports it; the multi-location scheduling surface is planned as the slot engine is extended. Planned
How this differs from the school-program tools
A number of studios photograph schools as part of their business — running picture day across a territory of schools, managing per-part handler arrangements where the school schedules and the studio shoots, coordinating retake days, and splitting revenue across studio, school, and platform legs. That workflow is a distinct product: schoolphoto.studio is the operator recruitment and operations home for that program.
Photo Studio Software is the general-studio surface. It is for a portrait business, a senior photographer, a family studio, or a commercial operation that may or may not also photograph schools. The booking engine, the galleries, the proofing system, and the agreements engine are the same substrate — the school-program operator tooling adds territories, per-part matrix, district scheduling coordination, and the school-side FERPA data wall on top of that substrate.
If you run a studio that does both general portrait work and school picture day, the two products share the same scheduling engine and the same agreements engine. They are separate operator surfaces, not separate software stacks. A photographer who wants to explore running school picture days as a program should start at schoolphoto.studio. A photographer who runs a general-purpose studio should start here.
On the family-facing side: when a parent visits pholio.photos, they see the school-photography product as a family member — claiming their child’s portraits, reviewing the gallery, and managing consent. That is a different entry point from a studio operator’s control surface. Photo Studio Software is the operator-side studio tool, not the consumer-facing family portal.
Common questions
Is this only for studios that photograph schools?
No. Photo Studio Software is built for any photography studio — portrait, family, senior, commercial, or any combination. School photography is a separate operator product (schoolphoto.studio). This platform is the general-studio surface: booking, galleries, proofing, and agreements for any session type.
What is the scheduling engine and how does it differ from a calendar booking tool?
The slot engine is the same scheduling core used across eight K–12 booking surfaces on the platform. Unlike a calendar-overlay booking tool, it treats each session as a distinct slot with its own identity, capacity, and availability state. Buffers between session types, multi-photographer availability, and fixed-slot booking are all native to the engine — not workarounds added on top.
Can one studio client see another client’s photos?
No. Galleries are tenant-isolated: a client sees only the images from their own session. The isolation is enforced at the data layer. A gallery link resolves only for the account it was issued to. No workaround, shared link, or guessable URL gives access to another client’s session.
Can I take orders and payments through the platform today?
Not yet. The storefront order engine, the product catalog, and the revenue ledger are wired. The payment processing and payout rail are switched off pending enablement. We say this plainly rather than describing the storefront as available. When it is enabled, client orders from proofed galleries will settle directly through the platform.
What agreements does the agreements engine handle?
The studio defines the agreement templates: session contracts, model releases, print releases, commercial usage agreements, or any other document the studio’s workflow requires. The engine routes each to the correct signing party at the correct point in the session lifecycle. Signed records are stored against the session they cover and are retrievable from the session record.
How does proofing work?
After images are uploaded to the client’s gallery, the client is notified that their proofing gallery is ready. They enter through a link, review each image in a structured flow, flag selects and passes, and submit. The studio sees the client’s selections in real time. The selections feed directly into the order step once the storefront is enabled. No email thread of numbered choices required.
Is this different from pholio.photos?
Yes. pholio.photos is the family-facing school-photography product: it is where a parent claims their child’s school portrait, manages consent, and accesses the parent gallery after picture day. Photo Studio Software is an operator-facing studio tool for running a photography business. The substrates overlap (same slot engine, same galleries system) but the audiences and products are distinct.
What does “honest-off” mean for the storefront?
It means the feature is built but not live: the code and the infrastructure exist, the seam is wired, and a dependency — in this case the payment processing and payout enablement — is not yet connected. The storefront is early access: the order flow and the product catalog will be available when the founder enables the payment rail. We name the gap rather than describing the feature as complete.
My studio runs picture day at local schools. Should I use this product or schoolphoto.studio?
If you run picture day as a recurring program across a school or district territory, the operator surface is schoolphoto.studio: it has the per-part handler matrix, territory management, district scheduling coordination, and the school-side data wall. Photo Studio Software is the general-studio surface. If your studio does both, the scheduling engine and agreements engine are shared under both surfaces.
Related products
schoolphoto.studio
The school-photo-program operator side: picture day across a district, territories, the per-part handler matrix, and the district scheduling surface. For studios that run school picture day as a program, not a general portrait business.
pholio.photos
The family-facing school-photography product: where a parent claims their child’s portrait, manages consent, and accesses the parent gallery after picture day. The consumer entry point, not the studio operator surface.
schedule.software
The scheduling core this platform’s booking engine is built on. One canonical slot-and-availability engine powering fixed-slot session booking, conference scheduling, audition slots, and all eight K–12 booking surfaces.
What is built and what is honest-off
Scheduling and booking on the shared slot engine — with fixed-slot session identity, multi-photographer availability, and per-session-type buffer rules — are built and running today. Consent-railed client galleries with structured proofing — tenant-isolated, permission-gated, selects flowing directly to order — are built and running today. The agreements engine for session contracts, model releases, print releases, and commercial usage agreements is built and running today. The storefront order engine, product catalog, and revenue ledger are wired and in early access: payment processing and payout to the studio are switched off pending enablement — no transaction is processed today and we say so plainly rather than burying it. The client-facing self-booking portal is in progress. Multi-location studio management and automated session follow-up are planned. We name all of this plainly.
Photo Studio Software is a Stanley Studios product — the same substrate behind schoolphoto.studio, pholio.photos, and the broader school-platform suite. Built for portrait, family, senior, and commercial studios: any photography business, not only school programs.