goldtag

Retrospective — From Tarot to Saju, the Evolution of AI Collaboration Two projects are done. 20 installments for Tarot Master, 20 for Four Pillars of Destiny (Saju). Across 40 total dev diary entries, my approach to AI collaboration kept evolving. It started with "wait, this actually works?" and ended with "how did I ever do this without it?" In this final installment, I look back at the journey. Tarot — Discovering Speed What I discovered in the Tarot project was speed. How fast you can ship code when collaborating with AI. Manually entering data for 78 tarot cards would have taken days — AI generated it in hours. Reading logic, UI components, state management — features that traditionally take 2-3 weeks were running in days. AI collaboration in the Tarot project was a "turbo booster." A tool that made things I already knew how to do dramatically faster. It felt like an extension of my existing development workflow, just with the speed dial cranked up...

Design Documents First — A Game Changer in the AI Era Write the document before writing a single line of code. Every developer knows the principle; few actually follow it. But working with AI, I discovered this isn't just a best practice — it's a productivity multiplier. Especially in a complex domain like Four Pillars of Destiny (Saju), the gap between having and not having design documents was night and day. The Tarot Approach — Conversation to Code Let's look back at the Tarot project. The workflow went like this: chat with AI about "how should we structure the data for 78 cards?", AI proposes something, and you immediately translate it into code. If it works, move to the next feature. If there's a problem, continue the conversation and iterate. This approach was fast and intuitive. For Tarot's complexity level, it worked fine. 78 cards, fixed interpretation texts, relatively straightforward reading logic. The entire structure fit in my head, so con...

Calculation School Settings as a Differentiator — "Same Chart, Different Readings" "The reading I got from this app is different from another app." If you build a Saju app, you will inevitably face this question. Same birth data, different results — naturally confusing for users. Instead of hiding this issue, we decided to confront it head-on. That was the starting point for what we call "Calculation School Settings." Why the Same Birth Data Produces Different Results Four Pillars of Destiny (Saju) is a discipline with thousands of years of history. Over that time, numerous schools of thought emerged, each with subtle differences in calculation methods. The key differences boil down to four areas. Late Night Hour (Yajasi) handling. For someone born between 11 PM and midnight, how do you determine the Day Pillar? One school says the day changes at 11 PM. Another says it changes at midnight. This single difference can change the entire Day Pillar, which ...

Capturing Users with Content — Celebrity Saju, MBTI, and the Five Elements Quiz No matter how many features a Saju app has, the act of "checking my chart" is a one-time event. You visit for the first time, see your reading, find it interesting, and then what? There's no reason to come back. We found the answer to this problem in content. The Difference Between Features and Content Features show results when a user provides input. Saju analysis, compatibility analysis, daily fortune. These are the app's core, but they don't inherently drive repeat visits. Your Four Pillars don't change. Content is different. Things to read, explore, and share. "So this is what that celebrity's chart looks like," "My MBTI connects to my Day Master this way," "Which of the Five Elements is strongest in me?" Content that sparks curiosity draws users back. Recognizing this distinction was one of the project's turning points — the moment ou...

Feature Explosion — Compatibility, Daily Fortune, Tojeong Bigyeol, and Beyond Once the Saju analysis engine stabilized, ideas started flooding in. Compatibility analysis, daily fortune, Tojeong Bigyeol (a traditional Korean fortune book). The problem was that each of these features would normally be a project-sized effort on its own. But with AI as a collaborator, the story was different. The Foundation That Made Expansion Possible The rule-based engine and AI interpretation layer covered in earlier installments — this hybrid architecture — became the critical foundation for feature expansion. Heavenly Stem and Earthly Branch calculations, Five Elements identification, Ten Gods analysis, combination and clash detection — all of this logic was modularized. Adding new features didn't require starting from scratch. Take Compatibility Analysis (Gunghap) as an example. Analyzing each person's chart individually was something the existing engine already did. The only new layer ne...

Deployment and Infrastructure — Running a Live Service at $0 The Reality of $0 Monthly Server Cost The biggest enemy of side projects is server cost. No matter how good the idea, if monthly hosting and API bills become a burden, the service eventually gets shut down. Between "what you want to build" and "what you can sustain" lies a wall called cost. This Saju app's total operating cost is $0. Excluding the domain name, hosting, API, CDN, and SSL are all free. Here's how that's possible — and what we gave up in return, honestly. Architecture: Static + Serverless The entire infrastructure rests on two pillars. Static hosting via GitHub Pages. We serve the React app's build output — HTML, CSS, JS, and images — through GitHub Pages. It's free for public repositories, includes a built-in CDN, and HTTPS is automatically configured. AI API proxy via Cloudflare Workers. If the browser called the Groq API directly, the API key would be exposed. ...

SEO and Content Strategy — Search Optimization for the Saju Domain The App Was Done, But... Analysis engine, AI interpretation, UI. All the core features of the Saju app were in place. But there was one critical problem. This app is a Single Page Application (SPA). A React-built SPA is basically an empty HTML shell where JavaScript renders everything. When Google's crawler visits, it sees a blank page. No matter how brilliant the Saju analysis engine, if search engines can't find it, users won't come. The SPA SEO Problem SPA's SEO challenges are well-documented, but they're trickier than expected when you actually face them. Yes, Googlebot can render JavaScript. But it doesn't render every page. There's a crawl budget, and JS rendering costs extra. New, small sites don't get favorable treatment. Meta tags are another issue. The "Gap-Ja Day Pillar detail" page and the "Eul-Chuk Day Pillar detail" page each need distinct title, d...

Five Elements Colors as UI — Balancing Eastern Aesthetics with Modern Design Color Came First When designing the Saju app's UI, the first decision wasn't layout — it was color. More specifically, the color system. Each of the Five Elements (Wood, Fire, Earth, Metal, Water) has a traditional color. Wood is green, Fire is red, Earth is yellow, Metal is silver or white, Water is blue or black. These five colors connect to every element in Four Pillars study. The Heavenly Stem Gap is Wood, so it's green. The Earthly Branch O (午) is Fire, so it's red. This color mapping has persisted for thousands of years. We adopted it directly as the app's design system. Just as tarot apps might use color to distinguish Major from Minor Arcana, our Saju app uses color to represent the Five Elements. But there's a key difference: tarot colors serve classification, while Saju colors carry inherent meaning. Designing the Five Colors Using raw primary colors would be painful on ...

The Magic of Gungtong Bogam — Prompt Engineering and Reference Data "Just Write It Well" Doesn't Work Once the rule engine was complete, structured analysis data started flowing out as JSON. Five Elements ratios, Ten Gods (Sipsin) relationships, the Favorable Element (Yongsin), combinations and clashes. Accurate data. Now we needed to hand it to AI and transform it into "human-readable interpretation." At first, I thought it would be simple: pass the data and say "interpret this well." The result was disappointing. "Wood is strong. Your personality is upright and straightforward." Not technically wrong, but generic enough to apply to almost anyone. It was miles away from the depth you'd expect from a professional Saju app. From Analysis Data to Prompt The first improvement was structuring the prompt. I organized the information passed to AI systematically. The core data included in the prompt: all four pillars with their Heavenly St...

Why You Can't Leave It All to AI — The Case for Hybrid Architecture Same Question, Different Answers "Give me the Four Pillars reading for a man born on May 15, 1990, at 6:00 AM." Early in the project, I asked AI this question three times. All three responses sounded convincing. The problem was that across those three answers, the Day Pillar came back in two different variations — once as Gap-Jin and twice as Eul-Sa. When the Day Pillar, the very foundation of a Four Pillars (Saju) reading, differs between attempts, every interpretation built on top of it collapses. That single experiment settled the matter: you cannot let AI directly calculate the Four Pillars. The Danger of the AI Black Box Why does this happen? Setting up the four pillars is far more than a simple date conversion. The Year Pillar doesn't change on January 1st. It changes at the Start of Spring (Ipchun), one of the 24 solar terms. In 2024, the Start of Spring fell on February 4th at 5:27 PM. S...

Testing and Verification --- Quality Assurance in a Domain with Multiple Right Answers When "Correct" Has More Than One Definition In most software, testing is straightforward. Check that 1 + 1 equals 2. There is one right answer --- it is either correct or it is not. Testing a Saju app is fundamentally different. For the same birth date and time, whether you apply True Solar Time correction, how you handle the Late Night Hour (Yajasi), and which school's rules you follow can each change what counts as the "right answer." When professional App A and professional App B produce different results, neither is necessarily wrong --- they may simply be applying different settings. In this situation, how do you prove that "our app is accurate"? That question was the starting point for the testing strategy. Cross-Verification Against Professional Apps The first step was comparing our results against existing professional apps. I revisited the apps benchmar...