REKWIZYTOR
A prop management system for theatre and film productions — from photograph to catalogued asset in seconds, powered by Gemini Vision API.
PROBLEM
"Prop masters in theatre and film productions spend hours manually cataloguing hundreds of items — each requiring a description, condition, location, and production assignment. The work is repetitive, error-prone, and hard to search."
REAL ORIGIN
The project grew from a concrete problem raised by prop masters working at a theatre in Silesia. Browsing Excel sheets, notes, or photos on private phones — no single source of truth, no control.
HYPOTHESIS
If a photograph is enough to identify an object — it's enough to catalogue it. One image should generate a full record with no manual data entry.
PRODUCT
ARCHITECTURE
Firebase dropped out early — functionally inconsistent and outside my comfort zone. PocketBase isn't Postgres, so no Row Level Security. Supabase gave me Postgres with RLS at the database layer: even if the application has a bug, the database enforces user data isolation on its own. Security as an infrastructure property, not an application concern.
WHAT DIDN'T MAKE IT AND WHY
Three features didn't reach the final prototype. Each for a different reason — and each after a conversation with the prop masters who were going to use it.
The prototype worked — props assigned to specific locations in storage. After a closer look it turned out that storage locations change between productions too frequently for a map to hold any value. The feature reached prototype stage and stayed there.
Built, tested, working. Dropped deliberately to hit the deadline with the core features complete. A complex infrastructure with too little added value for the user at this stage — a classic trade-off between technical capability and product priority.
The clearest example of admitting I was wrong. A real-time list showing who is handling which prop at which scene — theoretically useful. In practice, work on stage is more automatic than I assumed, and real-time sync would have introduced more problems than benefits. I found this out in conversation with the users, not through technical analysis.
All three decisions came from conversations with the people who were going to use the app — not from my own assumptions. In a corporate context that input comes from a PM, QA and UX. Here I had direct access to the end user — and that's where the priority changes came from.
Outcome
The system works end-to-end — from photo to searchable catalogue, with no manual data entry. Tested live with the prop masters it was built for — their feedback shaped the final feature set (see section 04). The technical goal was fully achieved; further rollout stalled at the theatre's organisational level, not the product's. Lesson for next time: a structured brief with the stakeholder before the first commit saves more time than any refactor.