Oslavu was a SaaS project meant to help event organizers choose better dates by analyzing conflict risk between events, venues, and audience overlap.

I believed event organizers had a painful and expensive decision problem: choosing the wrong date could reduce attendance, sponsorship value, and event ROI.

I thought this mattered because many organizers still made date decisions manually, using Google searches, spreadsheets, and assumptions about competitor activity.

My original vision was a practical tool that would turn this into a structured decision: input event parameters, get a conflict score, and compare options with clear reasoning.

I started by building an MVP in Cursor (vibe-coded) and treated the product as a learning-plus-validation process, not a polished launch.

• Most of my time went into learning tools and shipping quickly with AI-assisted development.
• I contacted event agencies across Czechia through personalized outreach emails.
• I had several meetings with agencies and used those conversations as primary product input.
• I iterated the MVP repeatedly based on feedback: added features, adjusted options, refined outputs.

This phase was less about growth and more about compressing the loop between assumptions, feedback, and product changes.

The product combined event data and scoring logic to estimate scheduling risk for candidate dates.

• Conflict scoring: each date received a risk score based on known nearby events and expected audience collision.
• Overlap logic: the model considered event category similarity, expected attendance overlap, and timing proximity.
• Data usage: I aggregated event data from APIs and scraping, then normalized it into comparable records.

The goal was not perfect prediction. The goal was better decisions with explicit trade-offs and fewer blind spots.

Most agencies I spoke with reacted positively. An important result was segmentation clarity: I learned which agency profiles had enough planning complexity to care, and which did not.

On the product side, the MVP was functional and delivered practical value in discussions. Users could understand the logic and use it to evaluate date options faster than manual research.

The biggest insight came from willingness-to-pay conversations. Traditional LLM tools such as ChatGPT and Perplexity could replace meaningful parts of my original value proposition.

That created a hard monetization problem: if users can approximate the answer with general AI tools, they need a stronger reason to pay for a dedicated product.

The real painful problem was different: manual communication with venues (calls, availability checks, pricing confirmation) consumed major planning time.

Based on that discovery, I shifted direction from date recommendation only to date + available venue recommendation.

• Geographic focus: Brno, where local network effects were strongest.
• Distribution strategy: partner directly with venues and integrate real availability data.
• Intended edge: solve workflow friction (coordination time), not only informational uncertainty.

• I secured only a limited number of venue partnerships.
• Partnership growth was slower than required for a scalable supply side.
• Fixed costs rose while revenue did not reach sustainable levels.
• I ran out of capital before proving a repeatable model.
• I was also searching for a technical co-founder and did not find the right fit in time.

In short: the product quality improved, but the business-side constraints moved faster than my ability to de-risk them.

I built Oslavu with a modern web stack and AI-assisted workflow, optimized for fast iteration and practical experiments.

• Next.js + TypeScript + Tailwind: fast UI iteration, strong structure, and clear maintainability.
• Supabase (PostgreSQL + pgvector): relational storage for event entities plus vector similarity for deduplication and semantic matching.
• OpenAI: used for extraction, normalization, and overlap reasoning where strict rules were insufficient.
• Firecrawl + external APIs: combined scraping and API ingestion to increase event data coverage.
• Architecture decisions: API-route based service layer, explicit error handling, and modular conflict-analysis services to support rapid iterations.

For non-technical readers: this stack let me test business assumptions quickly without building heavy infrastructure first.