1 Dracma started with a simple question: why does finding a lost item still depend so heavily on disconnected messages, isolated spreadsheets, and photos with no context?
The answer is not simply “there is no catalog.” Lost and found involves people in anxious moments, teams that need to operate quickly, and information that should not be public by default. The challenge was to turn that problem into a simple experience for visitors without oversimplifying the work and responsibility of the team managing a space.
A space, not just a list of objects
The central model in 1 Dracma is the lost-and-found space. A space can represent an event, mall, airport, institution, or any location responsible for receiving and returning items.
Each space has an institutional profile, its own contacts, registered items, and a visibility policy. This lets the same platform serve locations that want to appear in public search as well as operations that need to share a catalog only with authorized people.
For someone who lost something, the flow is straightforward:
- find the right space;
- browse available items;
- open photos and details sufficient for identification;
- contact the team or submit a claim.
For the responsible team, an authenticated area supports creating spaces, configuring profiles, registering items, managing photos, and following requests.
Privacy as a product rule
One of the most important parts of the project is that visibility is not an interface detail. It is a domain rule.
Spaces can be public or private. Items can inherit a space’s visibility or remain internal. A private catalog is only accessible through a shared link with an active opaque token. Institutional contacts are shown only when the space policy permits it.
That prevents an apparently harmless search from exposing information that should not be open. It also makes a choice explicit that many applications leave to unclear defaults: who can see what, in which context, and for how long.
Claiming is not the same as listing
Listing an item is simple; associating it with the right person is the sensitive part.
In 1 Dracma, a claim requires authentication and an identification message. The item stops being available for conflicting requests while the team evaluates the case. Conversations preserve context between visitor and operation without turning the public catalog into an open channel for personal data.
Public actions are also limited by origin and account, with optional Turnstile integration to reduce abuse in published environments.
A small architecture with clear boundaries
The frontend is built with React, Vite, and TypeScript. The application runs on Cloudflare Pages and uses Pages Functions for its edge backend.
Responsibilities are intentionally separated:
- Cloudflare D1 persists spaces, items, claims, conversations, and metadata;
- Cloudflare R2 stores photos, served through a proxy that enforces access rules;
- Pages Functions expose public, administrative, and visitor routes;
- Supabase Auth provides Google login and PKCE sessions;
- Turnstile can protect public flows against automated abuse.
It is not a huge architecture, and that is the point. At this product stage, the goal was to choose managed components that are close to each other and sufficient to operate a real workflow without creating unnecessary infrastructure.
What I am still exploring
The project already covers discovery, visibility, cataloging, contacts, claims, and conversations. The next challenges are closer to operations: item maintenance, photo management, administrative workflows, and the learning that only appears when real organizations start using the tool.
Building 1 Dracma has been a valuable product and engineering exercise. Technology needs to disappear for someone trying to recover something important; at the same time, it needs to give the responsible team clear, auditable, and secure controls.
You can explore the project at 1dracma.com.