MedusaWatch · From a real need to a working prototype in two days

MedusaWatch is a web app that helps you choose, before leaving home, which of Mallorca’s beaches have the lowest estimated chance of jellyfish. It combines each beach’s orientation with wind data and shows the risk level on a map.

I built the first working prototype in two days, starting from a specific need and a defined PRD. The days after that went into fixing bugs and refining the UX and UI, especially on mobile. My role covered product definition, UX/UI, directing the work with AI, frontend, QA, and launch. AI proposed options and sped up production; I decided what to build, how it should behave, and when the result was good enough to move on.

The project came from connecting a real need with local knowledge. A friend planning a trip to Mallorca told me she was worried about running into jellyfish and didn’t know how to see it coming. At the same time, I remembered something a friend from Menorca had told me: locals watched the wind direction to decide which coast to go to and lower their chances of finding jellyfish.

That local knowledge became a product hypothesis. Before building, I ran some checks and did early AI-assisted research to understand the link between wind, coastline orientation, and possible jellyfish build-up, and to judge whether it could carry over from Menorca to Mallorca. The exploratory research couldn’t promise there would be no jellyfish, but it gave enough grounds to form a product hypothesis, define the problem, and turn it into a PRD.

The exercise started from a specific question: how far could I get by combining a well-defined PRD, my front-end knowledge, and AI’s ability to execute? The point wasn’t whether AI could generate an isolated interface. It was to test whether this way of working could take me from a defined need to a first working prototype in very little time. My job was to steer the process, understand what was built, and stay in control of the decisions.

The PRD reduced ambiguity before any code was written. It defined the problem, the main use, and a small scope:

• Help people make a decision before going to a beach.
• Turn weather data that is hard to read into a clear signal.
• Show options across all of Mallorca, not a single data point per area.
• Work on desktop and mobile.
• Rely on free services and be publishable without a backend.
• Make clear that the risk is an estimate, not confirmation of actual sightings.

During those same two days, I tested the idea further through traveler forums, app reviews, and competitor analysis. The research gave early support to the hypothesis and revealed an important tension: solutions based on sightings are reactive and depend on someone reporting first. MedusaWatch’s opportunity was to help people decide ahead of time.

AI significantly cut the time it took to reach a first tangible version: it generated implementation proposals, explored alternatives, and turned decisions into code at a speed I wouldn’t have reached working alone from scratch.

But faster execution didn’t remove the need to know what was happening. My front-end knowledge is what let me read the overall logic, judge whether each proposal was feasible, and steer the next iteration.

• I defined the problem, the scope, and the PRD criteria → AI turned requirements into first working proposals.
• I decided how the product should behave and set priorities → AI proposed interface and implementation alternatives.
• I understood the architecture and assessed its implications → AI explained, generated, and reorganized parts of the code.
• I approved, rejected, or redirected the proposals → AI sped up cycles of change and experimentation.
• I tested, found bugs, and decided when to move on → AI helped find causes and suggest fixes.

I didn’t need to write every line by hand to stay responsible for the result. I did need to understand the pieces, set good constraints, notice when a solution didn’t answer the problem, and check it in the browser.

Showing wind direction and speed would have left the interpretation to the user. The product needed to turn that data into a useful answer: which beaches have a lower or higher estimated risk right now.

The model compares the wind direction with each beach’s orientation and adds wind speed as an extra factor. The result comes in three levels (low, moderate, and high) so the map can be scanned at a glance.

The key decision wasn’t to build a weather map. It was to use the data as raw material for an action: wind direction → relation to the beach’s orientation → estimated level → comparing options. This took the product from a regional reading to a specific signal for each of the 227 indexed beaches.

MedusaWatch doesn’t detect jellyfish or confirm sightings: it estimates a risk level from the wind. Turning that calculation into clear colors made the product more useful, but it could also suggest more certainty than the evidence supports.

To keep that difference visible:

• The interface talks about estimated risk, not confirmed presence.
• The levels help compare beaches without presenting the percentage as a certainty.
• A disclaimer appears on the first visit.
• The explanation stays available in the interface for later.
• The product is framed as a decision aid, not a safety guarantee.

The disclaimer wasn’t a legal add-on placed at the end. It was part of the experience: it had to inform without blocking every visit or competing with the main action.

The goal was to learn and launch, not to build more infrastructure than needed. I chose Vanilla JavaScript, HTML, and CSS, with no framework or build step. That kept the product logic visible while I was learning, reduced dependencies and setup, let me publish a static app on GitHub Pages, and let me work with external APIs without adding a premature backend.

The app was split into modules with separate responsibilities: orchestration, beach data, map, interface, and utilities. That structure made it easier to understand AI’s proposals, review changes, and fix one part without losing sight of the whole.

Simplicity didn’t remove external failures. The Overpass API can respond slowly, or not at all. To keep a service problem from leaving the screen empty, I added a 24-hour beach cache in localStorage and a fallback to earlier data when needed.

The map, search, beach list, legend, and time control had to work together on very different screens. The most likely context was mobile: checking the app before heading out or while planning the day. So I gave the mobile experience special priority and worked with two layouts:

• Desktop: a persistent side panel, the full list, and controls visible next to the map.
• Mobile: the map as the main surface, a bottom panel for the content, and search in an overlay.

The features stay the same, but their hierarchy changes. On desktop, the panel supports exploration; on mobile, it appears when the person needs it and gives the map back the focus when closed.

To complete the journey, I added a Directions button that opens each beach’s location in Google Maps. The time control shows how the risk may change over the next 24 hours, so people can plan their beach ahead of time. This feature came in a later iteration, once it became clear that the decision isn’t always made in the moment.

The first version proved the idea could work. Turning it into something publishable took a different kind of work: reviewing states, testing behaviors, finding bugs, and deciding what had to be fixed before launch.

During the pre-launch review, I:

• Added a visible error state for when an API failed.

• Fixed a calculation that showed the water temperature for the first hour instead of the current hour.

• Added a clear description of the product and when it updates.

• Connected the legend that explains the risk levels.

• Built in the first-visit disclaimer and permanent access to it.

• Reviewed the public documentation and legal notices.

  Evolution

  Real need → early research + PRD → prototype in two days → iteration → QA → launch on GitHub Pages

MedusaWatch went live on GitHub Pages on May 25, 2026. I didn’t run a launch or distribution campaign, so this result shows building and publishing, not adoption yet.

• 227 beaches in Mallorca, each with its own wind-based estimate.
• A risk forecast for the next 24 hours through a time control.
• Experiences adapted to desktop and mobile, with direct access to Google Maps.
• Caching and fallback data to reduce dependence on the Overpass API.
• Modular code, a public repository, and deployment on GitHub Pages.

The exercise proved the idea was technically feasible and turned a two-day prototype into a publishable product, while I kept a clear understanding of the main decisions. It isn’t a shift toward “doing everything”: it’s a natural extension of how I work, understanding what an idea needs to move forward and learning what I need to shape it. Here, AI expanded what I could build, and frontend let me steer it.

I don’t have adoption or user impact results to share yet. The app is live, but formal validation with real people is still pending.

Explore MedusaWatch (opens in a new tab) · Review the code (opens in a new tab)

The product starts from a reasoned hypothesis and exploratory research, but a working prototype is not the same as a validated problem. The next tests with real users will need to check:

• Whether the risk level is clear without prior explanation.
• Whether people understand that it’s an estimate.
• Whether the map actually helps them choose an option before heading out.
• What information they need to trust the recommendation.
• Whether the hourly forecast helps them choose a beach for that day or the next.
• How tourists, families, and frequent residents use the product.

Other product improvements still on the list: map accessibility, a contrast review of some indicators, multilingual support, an installable version, and expansion to other islands.