라벨이 Tarot인 게시물 표시

Retrospective: Building a Side Project with AI, and What Comes After

Retrospective: Building a Side Project with AI, and What Comes After Looking Back on a 20-Part Journey "I want to build a webpage that does tarot readings." One sentence. That's where this project started. Designing data for 78 cards. Setting the mood with dark navy backgrounds and gold text. Creating animations where cards float as if breathing. Solving dozens of mobile issues. Twenty installments documenting the entire process. In this final part, I want to step back and view the project from a high altitude. The moments AI genuinely helped and the moments it didn't. The collaboration methodology this project crystallized. And the fundamental value of building a side project with AI. The Full Project Timeline Here's the Tarot Master development process in chronological order. Idea refinement and tech stack selection: one day. Card data and interpretation text for 78 cards: two days. Core reading functionality and UI: three days. Animations and micro-interac...

The Vibe Coding Trap and Intent-Based Collaboration

The Vibe Coding Trap and Intent-Based Collaboration The Sweet Temptation of "Just Let AI Do Everything" "GPT can build that in five minutes." Whenever I hear this, I feel conflicted. It's not wrong. Tell an AI "build me a tarot app" and you get working code. Cards appear on screen. Click one and it flips. An interpretation shows up. Five minutes is an exaggeration, but thirty minutes is realistic. The problem comes next. "I want to change the card animation." "I want to add reading history." "The layout breaks on mobile." The moment these requests arrive, a developer working on top of code that AI produced in five minutes can do almost nothing. They don't understand the code. That's the vibe coding trap. And this post is about the core theme running through the entire Tarot Master project: the difference between vibe coding and intent-based collaboration. What Is Vibe Coding? Vibe coding means "letting A...

Mobile Optimization: The Surprisingly Tricky World of Mobile UX

Mobile Optimization: The Surprisingly Tricky World of Mobile UX When a Desktop-Perfect App Falls Apart on Mobile "It works fine on desktop, though." This might be the most dangerous sentence in frontend development. The first time I opened Tarot Master on my phone, the bottom of the screen was cut off. Card flip animations stuttered. Text was too small to read. Where did that elegant desktop experience go? Over half of all web traffic comes from mobile devices. For a lightweight entertainment app like Tarot Master, that proportion is even higher. On the commute, in bed, during coffee with a friend -- "Want to try a tarot reading?" happens on a phone. A bad mobile experience means losing the majority of your users. Bottom Tab Bar: Borrowing Native App Sensibility The most natural navigation pattern on mobile is a bottom tab bar. Instagram, WhatsApp, practically every native app uses bottom tabs. Placing primary actions where the thumb naturally rests is the foun...

Feature Expansion: Rapidly Adding User Features with AI

Feature Expansion: Rapidly Adding User Features with AI When "I Could Build This in a Day" Actually Takes a Day How long does it usually take to add a single feature? Plan it, design it, implement it, test it. On a company project, you'd budget at least a week. But with AI collaboration, the gut feeling of "I could do this in a day" genuinely becomes reality within a day. This part covers six features I added to Tarot Master: reading history, streaks, social sharing, PDF reports, Instagram story cards, and a free-choice mode. Each is an independent feature, but all share a common goal: making users stay longer and come back more often. Reading History: A "Tarot Journal" Powered by localStorage Sometimes you want to revisit a past reading. "What was that reading I got last week?" This need is perfectly served by a reading history feature. I built it entirely with localStorage, no database required. In a side project, a database dramatica...

Going PWA: Making a Web App Feel Like a Native App

Going PWA: Making a Web App Feel Like a Native App What If You Could Ship an App Without an App Store? "Shouldn't this be on the App Store?" That was the question I heard every time I showed Tarot Master to someone. When I explained it runs in a browser, people looked confused. It looks like an app, but it's not one? The technology that bridges that gap is PWA. Progressive Web App. The name sounds grand, but the concept is straightforward. Add a few configuration files to a website so it can be installed on a user's home screen, work offline, and even send push notifications. No App Store review, no developer registration fee. For side projects, it doesn't get better than this. Why PWA Makes Practical Sense for Side Projects Building a native app as a side project is nearly impossible. iOS requires learning Swift and paying a $99 annual developer fee, plus passing App Store review. Supporting Android adds Kotlin to the mix. Cross-platform frameworks like ...

The Deployment Journey: From GitHub Pages to Cloudflare and a $0 Bill

The Deployment Journey: From GitHub Pages to Cloudflare and a $0 Bill There's a wider gap than you'd expect between running code locally and putting it in front of the world. Deployment isn't just uploading files to a server. It's making architectural decisions about your infrastructure. Deployment Options for Side Projects Several platforms can host a frontend project: Vercel, Netlify, GitHub Pages, Cloudflare Pages. Each has distinct tradeoffs. Vercel, built by the Next.js team, is optimized for React deployments. It offers serverless functions and automatic preview deployments. But the free tier restricts commercial use and has bandwidth limits. Netlify occupies a similar niche. Build automation, serverless functions, form handling, lots of convenience features. The free tier is generous, but monthly build minutes are capped. GitHub Pages is the simplest option. Push static files to a GitHub repository and you're done. No serverless functions, no built-in b...

Winning with Content: Expanding SEO Territory Through Guides and Columns

Winning with Content: Expanding SEO Territory Through Guides and Columns Technical SEO optimization was done, but search traffic remained negligible. Feature pages alone couldn't cover the keywords people actually search for. I didn't need more app features. I needed content. Feature Pages Alone Won't Cut It Tarot Master had only a handful of core feature pages: homepage, reading mode selection, card selection, and results. No matter how well I optimized their meta tags, these pages didn't match the keywords people type into search engines. People do search for "free tarot reading," but they search far more often for informational terms like "tarot card meanings," "Major Arcana interpretation," "Celtic Cross spread guide," or "reversed tarot card meaning." Without content that addresses those queries, even the best app in the world won't attract search traffic. The reality of search traffic is unforgiving. No ma...

I Should Have Thought About SEO From Day One: A Belated Optimization Story

I Should Have Thought About SEO From Day One: A Belated Optimization Story Two weeks after launch and my Google search traffic was exactly zero. It turned out that from Googlebot's perspective, my site was an empty HTML file. That's when I finally understood the fundamental limitation of a React SPA. The Shock of Zero Search Traffic After deploying the project on GitHub Pages, I checked Google Search Console daily. Zero impressions, zero clicks. After a week with no change, I told myself "indexing probably hasn't happened yet." By week two, I faced reality. The URL Inspection tool revealed that Google's rendered version of my pages was nearly empty. Just a title tag and a loading spinner, no actual content. The reason was simple. A React SPA only renders content after JavaScript executes, and Googlebot doesn't always execute JavaScript perfectly. The Fundamental SEO Problem with SPAs Traditional websites send fully formed HTML from the server. When G...

Adding AI Interpretations: Building a Serverless API Architecture

Adding AI Interpretations: Building a Serverless API Architecture If the same interpretation appears every time a card is flipped, interest dies by the second reading. Real-time AI interpretation wasn't a nice-to-have. It was essential. The question was cost. It Started with Static Text In the early version, each of the 78 cards had a pre-written interpretation. Counting upright and reversed meanings, that meant 156 text blocks stored in a JSON file, matched and displayed whenever a card was flipped. The advantages were obvious. Zero API calls, zero cost, zero latency. The interpretation appeared the instant the card turned. But there was a fatal flaw: once you'd seen an interpretation, it was the same every time. The heart of tarot reading is that "even the same card carries a different message depending on context," and static text couldn't deliver that. The Moment I Decided to Go AI The tipping point was the three-card reading. When Past, Present, and Fut...

The Power of Micro-Interactions: How Tiny Animations Transform Perceived Quality

The Power of Micro-Interactions: How Tiny Animations Transform Perceived Quality The features were done, but something felt hollow. Clicking a card produced a result, sure, but there was zero sense of actually receiving a tarot reading. The difference, I discovered, wasn't about functionality. It was about animation. A Motionless Card Is a Dead Card The core experience of a tarot reading is the act of choosing. Out of 78 cards, which one calls to you? In a real-life reading, you spread the cards out and hover your hand over them until one feels right. I needed that same sense of aliveness on screen. Initially, the cards were just static images in a grid. Clicking one flipped it, technically speaking, but the cards on screen felt like buttons in an e-commerce catalog. Not tarot cards. Product thumbnails. First Attempt: The Floating Animation I added a subtle floating motion to unselected cards. A gentle up-and-down loop, barely two or three pixels of travel. Each card starts a...

The Celtic Cross Challenge — Solving a Complex Layout with CSS Grid

The Celtic Cross Challenge — Solving a Complex Layout with CSS Grid Ten Cards, One Ancient Pattern The Celtic Cross is the most complex tarot spread. Ten cards arranged in a specific pattern — six forming a cross in the center, four stacked vertically on the right — each position carrying its own meaning. This layout has been used for centuries, and I needed to reproduce it faithfully on the web. The problem is that this layout breaks every convention of typical web design. It's not a horizontal list, not a neat grid of equal cells, and not a scrollable feed. Cards need to be placed at specific coordinates. And to make it more interesting, the second card must overlap the first at a 90-degree angle. How do you build that on the web? Why CSS Grid Over Flexbox My first instinct was Flexbox. It handles one-dimensional layouts beautifully, and it worked perfectly for the One Card and Three Card spreads — just line up the cards horizontally with some spacing and you're done. B...

React Component Architecture — Designing Structure with AI

React Component Architecture — Designing Structure with AI A Pretty Screen With Tangled Code Is Still a Mess The color palette is finished. Stars drift in the background. The card-flip animation is smooth. All 78 images are secured. Now it is time to assemble all these elements into a working app. But if you start coding without a plan, you will inevitably regret it. In frontend development, component architecture is the structural framework of a building. No matter how stunning the exterior, if the frame is weak, walls collapse every time you add a feature or fix a bug. Especially in a project like a tarot app — with multiple reading modes and complex state transitions — the initial architecture determines how fast everything else proceeds. Start with the User Flow Before dividing components, I mapped out the user's screen flow. The journey has three stages: select a reading mode on the home screen, draw cards, and view the results. Breaking each stage down further reveals th...

The Hunt for Free Images — Copyright, Broken URLs, and Hosting Headaches

The Hunt for Free Images — Copyright, Broken URLs, and Hosting Headaches I Need 78 Images The screen design was complete. Stars drifting across the background, cards flipping with a satisfying 3D animation. The problem? There was nothing to show on the front of the flipped cards. A tarot deck has 22 Major Arcana and 56 Minor Arcana — 78 cards total. I needed images for all of them. Using images from a commercial tarot deck would mean licensing fees. I was not keen on investing hundreds of dollars into a side project. That meant finding free images. And that is where an unexpectedly long journey began. The Public Domain Trap: 1909 vs. 1971 The first thing that comes to mind for tarot images is the Rider-Waite-Smith (RWS) deck. Created in 1909 by Arthur Edward Waite with illustrations by Pamela Colman Smith, it is the standard of modern tarot. Most tarot apps use these images. "1909 — the copyright must have expired, so I can use them freely," I thought. Half right, half ...