Own product

Festarama

All your festival logistics in one place. Without opening 12 tabs.

View product →

Tech stack

  • Laravel 13.12 + PHP 8.3
  • MySQL 8
  • Blade + Tailwind 4 + htmx (no SPA)
  • Leaflet + OpenStreetMap self-hosted
  • Open-Meteo for weather (no API key)
  • Anthropic API for assisted scrapers
  • Plausible or GA4 (env-driven)

The technical challenge

Every festival is a rich record: lineup with schedules, nearby accommodation, transport options from 8 cities, surrounding POIs, the weather forecast, real tips. It is not free-form content, it is structured content that repeats in the same shape for every festival. The data model had to cleanly separate what belongs to the festival as a permanent entity, what belongs to this specific edition (dates, lineup, prices), and what belongs to the city.

Then comes the SEO part. Traffic comes from searches like "transport to {festival} from {city}" or "{festival} accommodation". Each combination is a landing page in its own right. The site has long-tail sub-routes per festival: `/{festival}/alojamiento`, `/{festival}/desde-{city}`, each with its own title, description, content and JSON-LD. Filters that only work with JavaScript would not cut it: the combinations have to be indexable.

The "For you" recommendation crosses the visitor's context (detected location, dates) with upcoming festivals to surface the most relevant one. It is scoring logic, not a trained model.

Process and decisions

Laravel + Blade + htmx, no SPA. For a site that lives off SEO, server-side rendering is the right call. htmx adds targeted interactions (filters, progressive loading) without dropping a whole JS framework on top. Less JS, less weight, better LCP.

Weather via Open-Meteo (no API key, no recurring cost) instead of OpenWeather or similar. Maps with Leaflet over self-hosted OpenStreetMap, not Google Maps: zero cost per load, zero surprise monthly quota when traffic grows.

To fill the database with real festivals we used LLM-assisted scrapers (Anthropic API). The LLM never enters production, only the ingestion pipeline: it downloads the festival's website, asks the model to structure the data according to the target model, validates it, and only then is it seeded. It is faster than writing scrapers by hand for each different site.

Traction

9 (MVP)Festivals with a complete record
accommodation + transport from 8 citiesLong-tail SEO pages per festival
Minimal (htmx, no SPA)Additional JS load
0€/month (OSM + Open-Meteo)Cost of maps and weather
MusicEvent, FAQPage, BreadcrumbList, ItemListJSON-LD

What does this mean for your project?

If you need an editorial site with structured, repeatable, filterable content (events, festivals, travel, restaurants, routes, trade fairs), this project proves you can build the data model, the per-combination SEO sub-routes and the editorial template without having to maintain a JavaScript SPA or pay monthly for every map or weather API.

It also serves as an example of a project built for SEO from day one. URLs by taxonomy and by combination (festival + city + category), structured data, indexable pagination, long records with a clear hierarchy. If your business model depends on organic traffic, this is how you build it.

And if your content pipeline benefits from LLMs to structure raw data (PDFs, vendor websites, messy spreadsheets), here the Anthropic API was used on the ingestion pipeline side and it works. The same logic applies to your case if you are loading external content from many sources in different formats.

Want something similar?

Tell me what you have in mind and I'll tell you what I can do.

Let's talk