REKWIZYTOR
System zarządzania rekwizytami dla produkcji teatralnych i filmowych — od fotografii do skatalogowanego zasobu w ciągu sekund, z pomocą Gemini Vision API.
PROBLEM
"Spędzają godziny na katalogowaniu ręcznym lub tego nie robią w ogóle — co prowadzi do powiększającego się chaosu. Z czasem sam fakt tego ile trzeba naprawić skutecznie zniechęca do działania."
REALNE ŹRÓDŁO
Projekt powstał z konkretnego problemu zgłoszonego przez rekwizytorów pracujących w jednym ze śląskich teatrów. Przeglądanie arkuszy Excel, notatek lub zdjęć na prywatnych telefonach — brak jednego miejsca, brak kontroli.
HIPOTEZA
Jeśli zdjęcie wystarczy do identyfikacji — wystarczy też do katalogowania. Jeden obraz powinien generować pełen rekord bez ręcznego wprowadzania danych.
PRODUKT
ARCHITEKTURA
Firebase odpadł szybko — funkcjonalnie niespójny i poza moją strefą komfortu. PocketBase to nie Postgres, więc brak Row Level Security. Supabase dał Postgres z RLS bezpośrednio na poziomie bazy: nawet gdyby aplikacja miała błąd, baza sama pilnuje izolacji danych między użytkownikami. Bezpieczeństwo jako właściwość infrastruktury, nie warstwy aplikacji.
CO WYPADŁO I DLACZEGO
Trzy funkcje nie trafiły do finalnego prototypu. Każda z innego powodu — i każda po rozmowie z rekwizytorkami które miały z tego korzystać.
Prototyp działał — rekwizyty przypisane do konkretnych miejsc w magazynie. Po wglądzie okazało się że miejsca trzymania grup zmieniają się między produkcjami zbyt często żeby mapa miała wartość. Funkcja osiągnęła prototyp i tam została.
Zbudowane, przetestowane, działające. Porzucone świadomie żeby wyrobić się z kluczowymi funkcjami w określonym czasie. Skomplikowana struktura przy zbyt małej wartości dodanej dla użytkownika na tym etapie — klasyczny trade-off między możliwościami technicznymi a priorytetem produktu.
Najbardziej sztandarowy przykład przyznania że nie zawsze ma się rację. Lista na żywo pokazująca kto zajmuje się jakim rekwizytem przy jakiej scenie — teoretycznie pomocna. W praktyce praca na scenie jest bardziej automatyczna niż zakładałem, a synchronizacja w czasie rzeczywistym wnosiłaby więcej problemów niż pożytku. Odkryłem to w rozmowie z użytkowniczkami, nie przez analizę techniczną.
Wszystkie trzy decyzje wyszły z rozmów z ludźmi którzy mieli używać aplikacji — nie z własnych założeń. Kontekst korporacyjny to ma PM, QA i UX. Tutaj był bezpośredni dostęp do użytkownika końcowego — i to z tego źródła przychodziły zmiany priorytetów.
Outcome
System działa end-to-end — od zdjęcia do przeszukiwalnego katalogu, bez ręcznego wprowadzania danych. Testowany na żywo z rekwizytorkami, dla których powstał — to ich feedback ukształtował finalny zakres funkcji (patrz sekcja 04). Cel techniczny został osiągnięty w całości; dalsze wdrożenie utknęło na poziomie organizacyjnym teatru, nie produktu. Wniosek na przyszłość: ustrukturyzowany brief z odbiorcą przed pierwszym commitem oszczędza więcej czasu niż jakikolwiek refactor.