DEV Community: Xianghua Feng

I Vibe Coded a Daily Tarot App in 2 Months with Cursor + Cloudflare — Here's What AI Can't Do (Yet)

Xianghua Feng — Sat, 28 Feb 2026 06:57:12 +0000

A few months ago, I had a clear idea for a project: a clean, free daily tarot reading site where people could draw cards and get meaningful interpretations — no paywalls, no dark patterns, no "your future is blocked, upgrade to unlock." The result is dailytarot.io, a fully working tarot reading web app featuring one-card, three-card, Celtic Cross, and Yes/No spreads, plus a full 78-card meaning library. It took me roughly two months of vibe coding to get there — and the journey taught me a lot about where AI shines, and where it absolutely cannot replace a human eye.

The Stack: Why I Went All-In on Cloudflare

When I started the project, I wanted the simplest possible hosting setup that could still scale if the site somehow got traction. I landed on the Cloudflare full-stack combo:

Cloudflare Pages for hosting the frontend
Cloudflare D1 (SQLite at the edge) for storing card data, spreads, and interpretations
Cloudflare R2 for storing card images and static assets

The beauty of this trio is that they integrate seamlessly. D1 bindings slot right into your Pages functions, R2 is just an environment variable away, and the whole thing deploys from a GitHub push. Zero cold start anxiety, generous free tiers, and no AWS invoice trauma. If you're building a content-heavy side project and haven't tried Cloudflare's full-stack offering, dailytarot.io is basically a live demo of what it can pull off.

The Tooling: Cursor + Two Different AI Brains

My primary coding environment was Cursor with the built-in Composer 1.5. This was the workhorse — generating route handlers, building the card spread UI, writing the D1 query logic, scaffolding components, and iterating on layout. Composer is excellent for sustained, multi-file "build this feature" sessions where you're essentially pair programming with the AI and letting it hold context across your whole repo.

For debugging, I brought in Claude Opus 4.6 separately. Whenever something broke in a subtle or confusing way — a D1 migration not applying correctly, a card spread state management bug, an R2 presigned URL that worked locally but not in production — I'd paste the relevant context into Opus and ask it to reason through the problem. The difference in reasoning depth between the two models for hairy debugging tasks was noticeable. Opus would often surface the actual root cause rather than just suggesting surface-level patches.

The workflow looked roughly like this:

Composer 1.5 to scaffold and iterate fast
Claude Opus 4.6 when something made no sense and I needed genuine reasoning
Rinse, repeat, deploy to Cloudflare Pages

The Part AI Really Struggled With: Tarot Card Meanings

Here's the thing nobody tells you about building a tarot app: the hardest part isn't the code. The hardest part is the content.

Dailytarot.io covers all 78 tarot cards — Major Arcana and both suits of the Minor Arcana — each with upright and reversed meanings across multiple reading contexts (love, career, health, general guidance). That's a lot of interpretive content.

My initial assumption was: "I'll just prompt an AI to generate all the card meanings, review them quickly, and be done in a weekend." I was deeply wrong.

The Problem with AI-Generated Tarot Interpretations

When I asked AI models to generate tarot card meanings, I got text that was fluent, nicely formatted, and often subtly wrong in ways that matter to people who actually use tarot. The issues fell into a few categories:

Tone mismatches. Traditional tarot interpretation has a specific register — it's reflective, not prescriptive. AI-generated text tended to drift toward either generic self-help language ("embrace your inner strength!") or overly ominous warnings that would genuinely upset someone who drew a reversed Tower on a hard day.

Contextual inconsistency. A card's meaning shifts meaningfully depending on spread position. The Three of Swords in a "past" position reads very differently from the same card in a "future" position. AI would often produce meanings that ignored positional nuance or contradicted themselves across spread types.

Accuracy drift on esoteric details. Some cards carry specific traditional symbolism — Rider-Waite imagery, Thoth system variations, numerological associations — that AI would casually get wrong or blend into a mash. For users who know their tarot, this destroys trust instantly.

False positivity/negativity on reversals. AI models have a detectable tendency to soften reversed card meanings. Reversed cards aren't just "the upright meaning but slightly bad" — they often carry completely distinct archetypal weight. The AI kept flattening this distinction.

What I Had to Do Instead

I ended up doing a manual review pass on every single card meaning. Not just a skim — I cross-referenced traditional sources, checked positional logic, adjusted tone, and rewrote sections that were subtly misleading. This is what turned a "two-week project" into a two-month project.

AI was still useful here — it was a great first draft engine and a good sparring partner when I was trying to articulate why a meaning felt wrong. But a human had to make the final call on every interpretation that would actually appear on dailytarot.io. For a product where people are drawing cards during vulnerable moments in their lives, "good enough" AI output wasn't acceptable.

What Vibe Coding Actually Looks Like (The Good Parts)

I don't want to sound overly negative about the AI coding experience — because for the code itself, Composer was genuinely transformative. Here's where it genuinely saved me:

Feature scaffolding at speed. Saying "add a Celtic Cross spread with these 10 positions, store the draw in D1, and display results with card flip animations" and watching Cursor scaffold that across multiple files in one shot — that's the vibe. It would've taken me a week to write that by hand; Composer did a working draft in minutes.

Cloudflare integration boilerplate. D1 and R2 have their own quirks (binding declarations, wrangler.toml configuration, the way you reference env in Pages Functions). Composer just knew this stuff. I didn't have to spelunk through docs every time I needed a new integration point.

CSS and responsive layout. I have the design taste of a senior engineer but the CSS skills of someone who learned it in 2009. Composer handled responsive card grid layouts, spread diagrams, and the card flip animation CSS without me having to suffer through flex vs. grid debates.

Iteration speed. "This doesn't look right, move the card image to the left and make the interpretation text scroll independently" — done in 30 seconds. The feedback loop for UI iteration was genuinely fast in a way that made me feel like the product was alive.

Lessons Learned for Anyone Building a Content + AI Site

If you're planning to vibe code something where AI-generated content is part of the product (not just the tooling), here's what I'd tell myself at the start:

Budget real time for content QA. AI is a first-draft machine, not a publisher. Factor in human review time before you ship, especially if accuracy or tone matters to your users.

Domain knowledge is irreplaceable. The reason I could catch the AI's tarot meaning errors is that I spent time understanding tarot before building the app. If you're building in a domain you don't understand, AI content QA becomes nearly impossible.

Separate your "build fast" model from your "think deep" model. Using Composer for iteration and Opus for debugging was the right call. Don't use the heavyweight model for everything — you'll blow your budget. But don't use the lightweight model when you actually need reasoning depth.

Cloudflare's free tier is shockingly good for side projects. D1, R2, and Pages together cover a meaningful amount of traffic before you pay a dollar. For a project like dailytarot.io, it's essentially free infrastructure for a real production app.

The Result

Dailytarot.io is live, free, and covers the full 78-card tarot deck with multiple spread types. Every meaning has been human-reviewed. The app runs on Cloudflare's edge with zero servers to manage.

Would I do it again? Absolutely. The two months felt long in the moment, but compare it to building the same thing without AI assistance — that would've been six months at minimum, or I simply wouldn't have done it. Vibe coding got a real product shipped. The lesson is just that "vibe coding" doesn't mean "no judgment required." It means you bring the judgment; the AI brings the velocity.

If you draw a card today, I hope it's a good one. 🃏

I Built a 6,000+ Location Directory by Showing AI an Existing Website

Xianghua Feng — Tue, 23 Dec 2025 16:48:37 +0000

Full disclosure: I've never written code professionally. But last weekend, I built carwashin.co.uk—a directory with 6,051 car wash locations across the UK.

The key wasn't coding skills. It was finding the right reference and knowing how to use AI.

The Lightbulb Moment

My friend James in Manchester was complaining about finding decent car washes for 20 minutes. I was half-listening until he said: "Why isn't there just a simple website that lists them all?"

That got me thinking. Then I remembered something.

A few months ago, I needed to donate old clothes. I found this website: clothingbanks.co.uk. Simple, clean directory of clothing donation bins across the UK. Just a map, city pages, and location lists.

The thought: "Wait... this format would work perfectly for car washes."

That's when I realized: I didn't need to invent a new website structure. I just needed to replicate an existing one with different data.

The Plan (Such As It Was)

What I knew:

Clothing Banks website works well for locations
The format is simple and clean
If it works for donation bins, why not car washes?

What I didn't know:

How that website was actually built
What technology it used
How to build anything remotely similar

The hypothesis:
If I could show an AI tool what I wanted to replicate, maybe it could figure out how to build it.

Tool #1: Cursor - The AI That Learns from Examples

I'd heard about Cursor from people on Twitter. Downloaded it expecting to be overwhelmed.

First Conversation with Cursor

Me:

"I want to build a website similar to clothingbanks.co.uk but for car washes. Can you look at that site and understand its structure?"

Cursor:

"I'll analyze the site structure. Give me a moment..."

[Cursor actually visited the site and analyzed it]

"This site has:

Homepage with map showing all locations

Individual city pages (e.g., /london/, /manchester/)

List view of locations with addresses

Simple search functionality

Mobile-responsive design

I can build a similar structure for car washes. Should we start?"

Me (internally): "Holy shit, it actually understood what I meant"

Me (externally): "Yes, let's start with the homepage."

The Development Process (More Structured Than Expected)

Step 1: Analyzing the Reference Site

Me:

"What makes clothingbanks.co.uk work well? What should I keep and what should I change?"

Cursor:

"Good elements to keep:

Clean, simple design (not overwhelming)

Map-first approach (visual is helpful)

City-based navigation (logical for UK users)

Mobile-friendly (most people search on phones)

Potential improvements for car washes:

Add ratings/reviews (more important for paid services)

Include service types (hand wash, automatic, etc.)

Opening hours (donation bins don't have hours)

Photos (helps people recognize the place)"

This was already way more thoughtful than I would've been on my own.

Step 2: Building the Structure

Me:

"Let's build the homepage with a map like Clothing Banks, but for car washes."

Cursor started creating files:

Creating index.html... Setting up map integration... Adding location markers... Styling with CSS...
What I did: Watched and occasionally said "can you make that bigger?" or "different color?"

What I learned: Having a reference site meant Cursor knew exactly what "a page like Clothing Banks" meant. I didn't need to describe every detail.

Step 3: City Pages Structure

Me:

"Clothing Banks has pages like /london/ and /birmingham/. Can we do the same for car washes?"

Cursor:

"Yes, I'll create:

Individual city pages with same URL structure

Each page shows locations for that city

Map centered on that city

List of locations below map

How many cities do you want to cover?"

Me:

"All major UK cities. Like... 50+?"

Cursor:

"I'll create a template that can generate pages for any city. You just need to provide the city names and location data."

Me (thinking): "Wait, that's actually smart. One template, multiple pages."

I genuinely didn't know that's how websites worked, but it made perfect sense once Cursor explained it.

The Data Challenge (Where It Got Interesting)

Finding Location Data

Me:

"Clothing Banks probably has a few hundred locations. I need 6,000+ car washes. How do I get that data?"

Cursor:

"Several options:

Public business directories

Google Places API

OpenStreetMap data

Combination of sources

Should I help you collect data from public sources?"

Me:

"Yes, but how does that work?"

Cursor:

"I'll write a script that:

Visits public directory pages

Extracts car wash information

Saves it in a structured format

Removes duplicates

This is called web scraping. It's legal for public data."

The Data Collection Process

What Cursor built:

A script that visited business directory sites
Extracted names, addresses, postcodes
Geocoded addresses (turned them into map coordinates)
Saved everything in a JSON file

What I did:

Ran the commands Cursor told me to run
Checked the data looked correct
Asked "why did we get duplicates?" (learned about data cleaning)
Watched it process 6,000+ locations

Time: About 3 hours (mostly waiting for the script to run)

My contribution: Asking questions when something seemed weird

Understanding the Structure

Me:

"How does Clothing Banks organize their data? Can we look at their approach?"

Cursor:

"Looking at their site structure, they likely use:

Each location has: name, address, coordinates, postcode

Locations grouped by city

Static pages generated from data file

We can do the same. Here's how our data should look:
{
  "name": "Super Clean Car Wash",
  "address": "123 High Street",
  "city": "London",
  "postcode": "SW1A 1AA",
  "coordinates": [51.5074, -0.1278],
  "rating": 4.5
}
Does this make sense?"

Me:

"Yes! That's basically what Clothing Banks has but with extra fields like rating."

Having the reference site made understanding the structure SO much easier.

The Interactive Learning Process

When I Didn't Understand Something

Example 1: Map Integration

Me:

"How does Clothing Banks' map work? Is it Google Maps?"

Cursor:

"Looks like they use Leaflet with OpenStreetMap. It's:

Free (no API costs)

Open source

Lightweight

Easy to customize

Should we use the same?"

Me:

"Sure, but what's Leaflet?"

Cursor:

"It's a JavaScript library for interactive maps. Think of it as a tool that makes maps work on websites. I'll handle the implementation—you just tell me how you want it to behave."

Example 2: City Page Generation

Me:

"If I have 50 cities, do I need to manually create 50 pages?"

Cursor:

"No. We create one template, and it automatically generates a page for each city using your location data. Clothing Banks likely does this too."

Me:

"So I just add new cities to the data file and pages appear?"

Cursor:

"Exactly."

Me (mind blown): "That's actually genius"

The Design Process (Mostly Copying Smart Choices)

What I Took from Clothing Banks

1. Clean, Simple Layout

No flashy animations
White background
Easy-to-read fonts
Clear navigation

Me to Cursor:

"Let's use a similar clean design. No need to reinvent the wheel."

2. Mobile-First Approach
Clothing Banks works great on phones. That was clearly intentional.

Me:

"Make sure it looks good on mobile. That's probably where most people will use it."

Cursor:

"I'll use responsive design like Clothing Banks does. The map will adapt to screen size, and the list will stack vertically on mobile."

3. City-Based Navigation
The city list on Clothing Banks' homepage is perfect.

Me:

"Copy that grid of cities on the homepage. It's intuitive."

4. What I Changed

Added ratings (car washes are paid services, quality matters)
Made search more prominent (more car washes than donation bins)
Added photos where available (helps with recognition)

Deployment: Following the Path

Me:

"How is Clothing Banks hosted? Should I do the same?"

Cursor:

"I can't see their exact hosting, but for a static site like this, Cloudflare Pages is ideal:

Free

Fast global CDN

Easy deployment

Works great for directory sites

Want me to set it up?"

Me:

"Yes, but walk me through it."

The Deployment Process

Cursor:

"First, we need to put your code on GitHub"
[Helped me set up GitHub repository]
"Now, let's connect it to Cloudflare Pages"
[Opened Cloudflare, walked me through signup]
"Connect your GitHub repository"
[Showed me which buttons to click]
"Click 'Deploy'"
"Your site is live at carwashin.co.uk"

Time: 15 minutes

Number of commands I typed: Maybe 5

Things I understood: Maybe 60%

Did it work: Perfectly

What I Actually Learned

Concepts That Now Make Sense

1. Reference Sites Are Gold
Don't start from zero. Find something similar and say "like this, but for X."

2. Structure Matters More Than Code
Understanding why Clothing Banks organized things a certain way was more valuable than knowing how they coded it.

3. Data Structure Is Key
Once I understood how to organize location data (name, address, coordinates), everything else clicked.

4. Static Sites Are Powerful
Clothing Banks doesn't need a database. Neither do I. Static sites are:

Faster
Cheaper
Simpler
Easier to maintain

5. AI Needs Context
"Build a website" = vague

"Build a site like clothingbanks.co.uk but for car washes" = specific and actionable

What I Still Don't Fully Understand

Honest list:

How exactly maps get rendered on a page
What "responsive CSS" actually means technically
How geocoding works (addresses → coordinates)
The difference between static vs dynamic sites (I get the concept, not the implementation)
What Git actually does (I use it, but don't really get it)

But here's the thing: My website works. People use it. Do I need to understand all this?

The Skills That Actually Mattered

1. Pattern Recognition

Seeing that Clothing Banks' structure could work for car washes.

2. Clear Communication

Explaining to Cursor: "like this website, but different in these specific ways"

3. Product Thinking

Asking: "Why does Clothing Banks do it this way? Should we copy or change it?"

4. Knowing What to Ask

When stuck: "How does Clothing Banks handle this?" gave Cursor the context it needed.

5. Iterative Improvement

V1: Just locations and map
V2: Add search
V3: Add ratings
V4: Improve mobile layout
V5: Add photos

Each step was manageable because I had a reference point.

The Honest Cost Breakdown

Time Investment:

Finding reference site: Already knew it
Initial development: 6-8 hours
Data collection: 3-4 hours
Testing and fixes: 4 hours
Deployment: 15 minutes
Total: One weekend

Monetary Cost:

Domain name: £10/year
Cursor: Free tier (enough for this project)
Cloudflare Pages: Free tier
GitHub: Free tier
Total: £10

What I DIDN'T need:

Coding bootcamp: £8,000+
Hire developer: £2,000+
Web design course: £500+
Computer science degree: £50,000+

Mistakes I Made (Learn From These)

1. Not Studying the Reference Enough

I jumped into building before really understanding why Clothing Banks made certain choices.

Better approach: Spend 30 minutes clicking through the reference site first.

2. Assuming Copying = Easy

Just because I had a reference didn't mean it was instant. Still took a weekend of work.

3. Not Testing Data Quality

First data collection got lots of duplicates and errors. Had to clean it multiple times.

Lesson: Validate data early.

4. Ignoring Mobile Initially

Built everything on laptop. Checked phone Saturday night. Disaster.

Lesson: Test mobile from hour 1.

The Replication Strategy (For Your Next Project)

How to Use This Approach:

1. Find Your Reference Site
Look for sites that:

Solve a similar problem
Have good UX
Are relatively simple
Actually work well

2. Analyze What Makes It Work
Ask yourself:

Why is the layout structured this way?
What features are essential vs nice-to-have?
How is data organized?
What makes navigation intuitive?

3. Brief the AI with Context
❌ "Build me a website"

✅ "Build a site like [reference.com] but for [your use case], keeping [X, Y, Z] but changing [A, B, C]"

4. Iterate in Small Steps

First: Basic structure
Then: Core features
Then: Nice-to-haves
Finally: Polish

5. Keep the Reference Open
When stuck, look at how the reference site handles it.

What This Approach Works For

Good candidates for replication:

✅ Directory sites (like I did)
✅ Landing pages
✅ Portfolio sites
✅ Simple web apps
✅ Content sites
✅ Location-based services

Harder to replicate:

⚠️ Social networks (complex interactions)
⚠️ E-commerce (payment processing)
⚠️ Real-time apps (chat, collaboration)
⚠️ Anything with complex user permissions

Don't try to replicate:

🔴 Banking apps
🔴 Healthcare systems
🔴 Anything security-critical

Know your limits. I'm replicating simple structures, not complex applications.

For Other Non-Programmers

If You're Thinking of Trying This:

Start by finding your "Clothing Banks":

What site does something similar to what you want?
Doesn't have to be exact—just structurally similar
Simpler references are easier to replicate

Then:

Spend time really understanding why it works
Download Cursor (or similar AI coding tool)
Show it the reference and describe what you want
Let it build while you provide feedback
Ship something imperfect but functional

Don't:

Try to build from scratch with zero reference
Assume AI can read your mind without context
Get stuck in perfectionism

For Developers Reading This

I'm curious about your perspective:

Is using a reference site like this "cheating"?
Do you use reference sites when building?
What did I probably do wrong that I don't know about?

Genuinely want to learn from people who actually know what they're doing.

What's Next

Current status:

✅ 6,051 locations live
✅ Works like Clothing Banks (which was the goal)
✅ Mobile responsive
✅ People are using it

Potential additions:

User reviews (Clothing Banks doesn't have this)
Photos (would improve on the reference)
Booking integration (maybe too ambitious)

Reality: I'll probably add one or two features and call it done. The core problem is solved.

The Key Insight

The revelation wasn't:
"AI can write code for you"

It was:
"If you can show AI a good example of what you want, it can figure out how to build it"

Clothing Banks did the hard work of figuring out what a good UK location directory looks like. I just adapted that structure for a different use case.

That's not cheating. That's smart.

Try It Yourself

The website I built:
🚗 www.carwashin.co.uk

The inspiration:
👕 clothingbanks.co.uk

The process:

Find a site you like
Show it to Cursor
Describe your variation
Build in a weekend

Your turn:
What reference site could you adapt for your idea?

The Bottom Line:

You don't need to invent new structures. You don't need to code from scratch. You don't even need to fully understand how it all works.

You just need:

A good reference
AI that can learn from examples
A weekend

The barrier to building software isn't skill anymore. It's initiative.

Built by studying clothingbanks.co.uk and using AI to replicate the structure

Live at carwashin.co.uk

Find your reference. Build your version. Ship it.