Buburu: Building a Women’s Safety App in 48 Hours
ملخص
Pixel shares the story behind Buburu, a women’s safety app built in 48 hours after a frightening experience walking in Timișoara. The announcement covers its ladybug-inspired design, SOS and reporting flows, and technology including React, Spring Boot, OpenStreetMap, and OpenRouteService. It highlights how community-focused tools can help women look out for one another.
DEV Community
Buburu: A Women's Safety App Built in 48 Hours, Born From a Walk We Never Forgot.
This is a submission for the MLH x DEV Writing Challenge. Buburu is an app for women’s safety that we decided to create to help women feel safe during their walks. We named the app Buburu and its users ladybugs because there is not only one ladybug who saves Paris: we are all ladybugs who can save the world. The interface follows that theme, and users can choose their own colors. 🐞 We built the frontend with Java Script, React and Leaflet, used Java, Spring Boot for the backend, and stored our data in H2. Auth0 handled sign-in, OpenStreetMap provided the map, and OpenRouteService calculated walking routes. https://github.com/AmeliaDrag/UNIHACK2026 Why we built it During our first week at university in Timișoara, we went out to explore the city and get to know each other. A naked man started following us. A stranger who was walking his dog noticed what was happening, stayed with us, and walked us home. That story had a happy ending only because the man walking his dog had good intentions. It could have been much worse, and for many women it is. In a survey of 1,694 women in Romania aged 18 to 65, 95% said they had been harassed on the street (as reported by F-Sides). Across the EU, about three in ten women aged 18 to 29 (28.3%) reported having experienced stalking in 2021 (Eurostat). After that night, I wanted an app where my mom, my friends, and the girls I know could look out for each other. At our hackathon, we had 48 hours to build a first version. How we built it, step by step Sketch the flows. We drew the main screens on paper and worked out how people would move between the map, reporting, the account page, and SOS. Split the work. One teammate owned the Java backend. We divided the frontend by screen so we could work in parallel. Prototype the interface. After the team discussed what each screen should do, I laid out the pages. We used Canva, Figma, and AI tools to explore the design and develop the ladybug theme. Build the screens and connect the API. We used React 18 with JSX, Vite for local development and builds, Leaflet and React Leaflet for the map, the Auth0 React SDK for sign-in, and plain CSS for styling. The backend, in the words of the teammate who built it I built the backend with Java 21 and Spring Boot, using H2 to store users, trusted contacts, incident reports, and SOS alerts. Each report stores its coordinates, type, and expiry time. Trusted contacts are directional. If Ana invites Maria and Maria accepts, Maria receives Ana’s SOS alerts. For Ana to receive Maria’s alerts, Maria needs to invite her separately. For each walking route request, the backend queries active reports and converts their circular map zones into polygons for OpenRouteService. Computing those polygons on demand means expired reports are automatically excluded from the next request. If no route is found, the backend retries once without the avoidance polygons and returns avoidsReports: false, which the frontend uses to warn that the fallback route may cross reported areas. For the demo, the backend loaded a local OpenStreetMap export at startup to populate the 24/7 shop layer without a live data request. The hardest bug: Debugging the sign-in flow Clicking Sign in sent us back to the first page. In one attempt, the Account screen displayed Invalid state. While sign-in was broken, we couldn't test incident submission or SOS through an authenticated account. We first added type="button" to rule out an accidental form submission. The buttons were already outside a form, so we moved on to the app’s session state and the Auth0 callback. Stale guest state. A leftover guest flag could hide the sign-in controls. The app now checks that guest mode is actually enabled before honoring the flag. Two callback handlers. Both main.jsx and Auth0Provider handled the redirect. We removed the one in main.jsx so the provider owns the callback. API authorization. We fixed the app’s API authorization in the Auth0 dashboard and surfaced sign-in error...

Powered by Readybot.io