DEV Community

Cover image for I Vibe-Coded a Full-Stack Group Travel Planner in a Weekend — Then Found 8 Critical Security Issues
Kulsum
Kulsum

Posted on

I Vibe-Coded a Full-Stack Group Travel Planner in a Weekend — Then Found 8 Critical Security Issues

I built TripNest, a role-based group travel planner (Owner/Editor/Viewer permissions, itinerary planning, packing lists, group messaging) in a single weekend using Lovable. It looked release-ready by Sunday night. A free security scan found 8 critical issues before I ever pushed it live to real users.

🔗 Try it:

The Problem

I take a lot of short trips with family and friends — mostly road trips on holidays — and organizing them is always a mess:

Fragmented info — itineraries live in someone's Notes app, flights get shared as screenshots buried in a 200-message group chat, no single source of truth.
No safe way to share control — the person who did the planning has no way to let others view the plan without risking someone accidentally deleting a hotel booking or changing dates.
Trip chat lost in the noise — trip-related decisions get buried in unrelated group chat messages.

TripNest solves this with one space and a proper permission model.

How It Works: 3 Roles
Admins — the source of truth. Add/remove participants and planners.
Planners — can shape the itinerary without admin-level control (good for the friend handling activities, not the whole trip).
Participants — visibility without risk. Follow along, no ability to change dates or delete flights.

Core features: trip creation, role-based invites (with accept-before-join), collaborative day-by-day itinerary, flight info storage, packing lists, and a dedicated group message thread per trip.

Tech Stack
Lovable (initial build + iteration)
React + TypeScript
Tailwind CSS
Supabase (Auth + PostgreSQL)
Google Maps + OpenWeather (location/weather data)
Perfai Security (free access-control testing)
Building It

I started with one long, detailed prompt covering the product, users, pages, visual direction, workflows, and technical expectations — front-loading detail so Lovable could build a connected first version instead of screen-by-screen guesswork. That first pass nailed the design system (consistent typography, spacing, cards, buttons, forms), but it wasn't a finished product. I spent the rest of the weekend iterating: wiring components together, fixing edge cases, and adding features as I thought of them.

Challenges
Limited Lovable credits — every prompt draws from a chat budget, so vague prompts were expensive. I had to batch related changes and think through exactly what I wanted before sending a message.
Role logic across features — getting Owner/Editor/Viewer permissions to hold consistently across trips, itineraries, packing lists, and messaging took way more iteration than any single feature.
Sharing with non-users — inviting someone without a TripNest account initially just failed. Email invites needed a custom domain (which costs money), so I shipped a copy-link share feature instead.
"Published" ≠ "Ready to Release"

By Sunday, TripNest was a fully functional prototype — accounts, role-specific dashboards, persisted data, and a live published URL from Lovable. It looked done.

But publishing only proves the app runs. It doesn't prove the authorization model holds up under direct requests, that sensitive data can't be reached outside the intended UI, or that auth endpoints resist abuse.

So before calling it release-ready, I ran the live deployment through Perfai Security — not a code review, an actual test of the deployed app: mapping accessible routes, roles, and requests, then probing for weaknesses.

Result: 8 critical issues. None of them were visible from using the app normally — the UI looked polished, dashboards were properly separated, auth worked, normal flows worked fine. After fixing them, a second scan came back clean.

Takeaway
Lovable turned a detailed spec into a working app in a weekend — genuinely impressive. But "vibe-coded and published" isn't the same as "safe to hand real user data to." A security pass isn't a replacement for building the product, and it's not optional once you're handling accounts, permissions, and personal records — it's just part of the release checklist, same as checking mobile responsiveness or environment configs.

This is the prompt I used to build TripNest:

TripNest – Collaborative Travel Planner

Prompt I Used to make TripNest
Overview
Build a modern travel planning web app where users can create trips, collaborate with friends, build itineraries, upload travel documents, and receive travel recommendations.

Tech Stack
React
TypeScript
Tailwind CSS
Supabase (Auth + PostgreSQL)
APIs
Google Maps API – Maps and destination search
OpenWeather API – Weather forecasts
Amadeus API – Flight and hotel search
Authentication
Sign Up
Login
Forgot Password
Logout
Roles
Traveler: Manage their own trips and invite collaborators
Moderator: Moderate public content
Admin: Manage users and access the admin dashboard
Features
Dashboard
Trip CRUD
Shared itineraries
Search & filtering
File uploads
Notifications
Public & private trips
Database
Users
Trips
Trip Members
Itineraries
Comments
Notifications
Uploaded Files
Security
Role-based access control
Secure API authorization
Supabase Row Level Security (RLS)
Prevent unauthorized access, edits, file downloads, IDOR, and privilege escalation
Goal
Build a production-ready collaborative travel planner with multiple users, shared resources, CRUD operations, external API integrations, and secure authentication and authorization.

Top comments (0)