How PhotoTrackly is being built

First-party notes about the property-media workflow we are designing, the illustrative preview we can actually show, and the gaps we have not solved yet. Updated October 12, 2026.

The product question: who owns the next action?

A real estate media order can include photographs, drone imagery, video and a floor plan. A coordinator schedules the visit, a photographer captures the source files, editors prepare outputs, and a reviewer decides what is approved for client delivery. A calendar or folder can show only part of that journey. We are designing PhotoTrackly around one property job and its ordered services, next responsible person and explicit handoffs.

This is a product direction, not a customer-validated claim that we have saved studios time. Our target users are growing real estate photography and property media companies in the United States and Australia, not agents looking for a listing marketplace or consumers looking for a photography service.

See the intended shoot-to-delivery workflow and use the free checklist with existing tools.

What the illustrative preview really tests

Our publicly visible demonstration includes six job stages: Booked, Scheduled, Source files, Editing, In review, and Delivered. This is a fictional product concept rather than a deployed multi-tenant service. In its sample-model code, moving to the scheduled stage requires a manually assigned photographer. Moving into editing requires source-file records. A human approval action requires four review checks; a revision clears prior approval so a stale version does not silently count as delivered.

These checks are meaningful because they expose a single principle: a workflow stage is not enough without ownership and an explicit completion condition. The preview can be exercised in a browser using illustrative data, but it does not establish that production scheduling, storage, media uploads or client deliveries are available in a finished PhotoTrackly application.

Inspect the sample job model and transition rules and the unit tests for assignment, revision and approval.

Illustrative process and owner decisions — a teaching model, not a real customer job.

Brief → coordinator: record the property, ordered services and access instructions.
Schedule → assigned photographer: confirm date and current service brief manually.
Files → production owner: check the expected source sets before editing can proceed.
Review → human reviewer: distinguish approved files from specific revisions.
Delivery → coordinator: verify the agreed approved package and recipient.

What the prelaunch website has implemented

The website has two early-access registration forms and a server endpoint designed to validate consent and require confirmation of an actual saved registration before showing a success receipt. It records interest; it does not open a PhotoTrackly account. The source includes safeguards for retries, untrusted inputs and private withdrawal tokens. Actual production Google Apps Script configuration and live delivery still require their own operational checks.

We also publish answer-first operating guides, practical CSV worksheets and fictional annotated jobs. Those examples are designed to work with a studio current process, independent of PhotoTrackly availability. Our guides do not claim that fictitious properties are paying customers or that our illustrations are screenshots of a finished SaaS.

Read the registration receipt contract, the privacy-safe campaign attribution change, and the original worked-example release.

Current limits and what remains to prove

In development: the planned product covers jobs, services, manual scheduling, assignments, files, production status, human QC/revisions and delivery.
Not confirmed: automatic photographer routing, two-way calendars, payment integrations, AI photo editing, autonomous visual QC, migration tooling, launch date or pricing.
Not customer evidence: illustrated dashboards, fictional jobs, developer tests and hypothetical outcomes. These are not paid trials, measurable savings or testimonials.
Still requiring independent verification: the public deployment, end-to-end live registration receiver, actual AI-search citation traffic and the quality of future released workflows.

We will describe available features only after they can be verified in a released application. Our editorial policy explains our use of illustrative data and AI assistance. Share a correction through the registration form without including private client data.

Public implementation references

These links are to our own code and change history, not external endorsements. They let technically minded visitors distinguish deployed website work from the product still under development.

This page describes our website and design decisions as of October 12, 2026. It should be revised when real product capabilities, permissions or verified source evidence change.