Working prototype · Shootlo

Both sides of one shoot

Two phones, one booking. Every control here is the real one, and the state is shared: accept on the photographer and the customer's screen changes, because on the live product it is the same row in the same table. Thirteen steps, no sign-in, no data leaves the page.

CustomerAnanya, booking a shoot
PhotographerNikhil, taking the job
Step 1 of 13

What the app calls here

    

What this prototype does not show

The happy path is the short one. These five are where the product actually earns trust, and all five are built and tested on the server.

Nobody acceptsFive waves of three, 60 seconds each. If every wave lapses the booking is flagged for ops and the customer is offered a later time or a refund. It is never a dead end and the money is never silently kept.
Customer cancelsThe booking carries what a cancellation would cost, computed by the server. Free until the photographer sets off, then a ₹299 travel fee is kept for them. After they arrive, only ops can cancel.
Customer does not turn upThe photographer waits 15 minutes from arriving, calls through support, then the no-show button appears. Timestamps decide it, not whoever messages support first.
Two photographers accept at onceThe first conditional update wins and the other gets a 409 saying so in those words. This is a normal outcome, not an error state, and the app says who won rather than showing a failure.
The other two assistantsAsk Shootlo is the one a customer sees. Ops has a dispatch copilot that explains why a booking is not matching and what to do about it, and partner onboarding has a reviewer that reads a portfolio and an ID against the checklist and writes a recommendation a human approves. Both live on the web admin, not in the mobile apps.