Creating a Review System for the directory (Part 1) - Day 31
So here's the thing – I thought I'd spend maybe an hour adding a simple review feature to my travel directory. Three hours later, I'm staring at error messages and wondering why I ever thought this would be "quick and easy."
Quick summary
I'm building a personal review system for my Bali travel directory using Cursor AI, but what started as a simple rating feature turned into a database redesign nightmare. Here's what actually happened when AI coding met real-world complexity.
Why I'm even building this
Living here in Bali, I'm constantly discovering new restaurants and places to stay. I was originally just writing little reviews in a text field, but then a friend said something that made me rethink everything: "Why not just use a rating system? You could populate that data across the whole site."
That's one of those moments where you're like "Oh... that's actually brilliant." So instead of just writing random thoughts about each place, I decided to build a proper review system with ratings, images, and structured data.
The challenge I was facing
My travel directory had this basic text field where I'd write about restaurants and stays. Super simple, but not very useful for visitors who want quick information. I needed something that could:
Store structured ratings for different aspects (food, service, atmosphere)
Handle both my personal photos and official property images
Connect to my existing database without breaking everything
Actually work (spoiler alert: this was the tricky part)
What I tried first (spoiler: it created a mess)
I opened up Cursor AI and started chatting about what I wanted to build. The AI analyzed my project and came back with this whole implementation plan – database tables, API endpoints, components, the works.
At first, I was impressed. It mapped out everything:
Personal reviews table
Review aspects and ratings
Image handling system
Admin interface for managing reviews
I'm thinking "This is going to be so easy." Famous last words, right?
The database design rabbit hole
Here's where things got interesting (and by interesting, I mean frustrating).
When I checked my Supabase database, I already had a "reviews" table from earlier work. So I asked Cursor to analyze whether we should use the existing table or create a new one.
The AI used MCP (Model Context Protocol) to analyze my database structure and determined the existing reviews table was for external users, not my personal reviews. Smart, actually. It recommended keeping that for future user-generated content and creating a separate personal review system.
The image storage debate
Then we hit another decision point. Cursor created a separate table just for storing review images, but something felt off about this approach. In my other projects, I usually just store images in Supabase buckets and link directly to them.
So I asked: "Shouldn't we just store images in a bucket and link them directly instead of having a separate table?"
Turns out, both approaches work fine – it's really just preference. But since I'm used to the direct bucket approach, we simplified it by adding an images array to the main personal reviews table instead.
You know what's funny? I spent way too much time thinking about this. Sometimes the "perfect" database design is just whatever feels right for your project.
Here's how the system actually works
Once we sorted out the database structure, here's what we ended up with:
Database tables
Personal reviews: Main table with listing ID, ratings, story, images array
Personal review aspects: Different rating categories (food quality, service, atmosphere, etc.)
Bucket storage: For all the images I take at restaurants and stays
The rating system
Instead of just writing random thoughts, I can now rate specific aspects:
Food quality (for restaurants)
Service level
Atmosphere/ambiance
Value for money
Overall experience
Personal touch element
Here's what I really wanted to keep – the personal story aspect. Even with structured ratings, I still write a short story about our actual experience at each place. Because honestly, sometimes the best part of a restaurant isn't the food, it's that weird conversation you had with the owner.
The stuff that went wrong (oh boy, where do I start)
This is where my "simple one-hour project" turned into a three-hour debugging session.
Problem 1: The activities loop
For some reason, Cursor kept trying to build features for "activities" – which don't even exist in my current database structure. I kept telling it "just focus on stays and dining for now," but it would circle back to activities every single time.
I literally told the AI to skip activities completely, but it kept getting stuck in this loop of trying to create activity-related code. Super frustrating.
Problem 2: Wrong API versions
The AI started using the old Supabase JS client instead of the newer SSR version I'm actually using in the project. Small detail, but these version mismatches can break everything.
Problem 3: Missing admin interface
After all the database work was "done," I realized there was no admin page where I could actually manage these reviews. The AI said it was complete, but I couldn't find the interface anywhere.
When I pointed this out, it started building the admin page, but then got confused about routing and kept throwing "stay not found" errors.
How I'm fixing the problems
Honestly? I didn't fix everything in this session. Sometimes you hit a wall and need to step back.
Here's my plan for tomorrow:
Map out the exact structure I want before touching Cursor again
Focus only on stays and dining – forget activities for now
Fix the routing issues that are causing "stay not found" errors
Test each component individually instead of building everything at once
What this taught me about AI coding
Working with Cursor AI is amazing when it works, but it's not magic. A few things I'm learning:
Be super specific about scope: When I said "build a review system," the AI tried to build everything at once. Better to say "build just the database tables first, then we'll do the API."
Check your existing code: The AI can analyze your project, but it sometimes misses context about what you're actually using versus what exists in your codebase.
Break things into phases: The implementation plan approach actually worked well. Phase 1: database, Phase 2: API, Phase 3: components. When one phase works, move to the next.
Don't be afraid to backtrack: When the AI created that separate images table and it felt wrong, I should have trusted that instinct immediately instead of second-guessing myself.
What it looks like now (spoiler: it's not pretty yet)
Right now, the review system is half-built. The database structure is solid, but the frontend is throwing errors. Not exactly the smooth demo I was hoping to record.
But you know what? This is the real process of building stuff. It's messy, things break, and sometimes you spend three hours on something you thought would take one.
Lessons I'm taking from this
Scope creep happens even with AI – be crystal clear about what you want to build first
Database design decisions matter less than you think – just pick an approach and move forward
Test incrementally – don't build five features at once and then wonder why nothing works
Sometimes you need to sleep on it – tomorrow morning I'll probably see the routing issue immediately
What I'm working on next
Tomorrow I'm going to:
Fix the routing problems so the admin interface actually works
Add some placeholder data so we can see the system in action
Build the frontend components for displaying reviews on the actual listing pages
Maybe add that menu image feature I mentioned (because who doesn't want to see the menu before choosing a restaurant?)
Final thoughts
Building this review system reminded me why I love coding – and why it can be so frustrating. You think you have a simple problem, then you discover five other problems you didn't know existed.
But here's the thing: even though today didn't go as planned, I learned a ton about database design, AI coding workflows, and the importance of breaking complex features into smaller pieces.
Plus, once this review system is working, it's going to make the travel directory so much more useful. Instead of just listing restaurants and stays, I'll have structured data about what makes each place special.
Following along with my 60-day challenge to build a Bali travel directory? These behind-the-scenes coding sessions show the real process – mistakes and all. What's your experience with AI coding tools? Let me know in the comments.