With zero coding experience, they shipped a verified astrology app in 3 days

Links - Live app: https://ba-zi-app.vercel.app - The "Upgrade to unlock" button is free — no payment involved. - Public repository and full build history: https://github.com/Bilmatec/ba-zi-app   Category: The Vibe-Coding Builder   Project: Ba Zi — Four Pillars Chart App   One line: A working, verified Ba Zi (Chinese astrology) reading app, built and deployed by someone who had never written a line of code. Achievements   ·        Went from zero coding experience to a live, publicly reachable web app with its own feedback questionnaire inside 3 days. ·        The app takes a birth date, time, and city and produces a full Four Pillars chart, a five-element balance, a plain-English interpretation, a ten-year Luck Pillars life timeline, and a detailed reading tier behind a demonstration paywall. ·        User accounts and saved charts sit behind database-level row security, which I tested directly by confirming one account can't read another's data. ·        There are 62 automated tests covering the calculation engine, historical edge cases, and even the writing voice of the readings. ·        Every traditional calculation was cross-checked against independent outside sources before shipping. ·        The interpretation engine is rule-based and deterministic. This means there's no live AI call when someone reads their chart, so nothing shown to a user is invented, and there's no per-reading cost. ·        Some of the harder correctness problems it handles: historical daylight-saving time via the IANA time zone database, solar-term boundaries instead of calendar dates for the Chinese year/month, and an honest three-pillar chart (rather than a silent guess) when the birth hour is unknown. ·        The public repository has a clean, incremental commit history documenting every stage of the build with 31 commits across the three build days, all public.   Tools   Tool Role Claude Code (Opus 5 / Fable 5) Primary build partner — all code, testing, verification, deployment Claude (Cowork) Project scoping, design iteration, reusable skill creation Vite + React + TypeScript Application framework Supabase Authentication and Postgres database with row-level security Vercel Hosting, with automatic deployment on every push GitHub Version control and public build history lunar-typescript Chinese calendar and solar-term calculations Luxon + IANA time zone database Historically accurate time zone and DST correction Open-Meteo geocoding API City search resolving to precise time zones Vitest Automated test suite Google Forms Structured user feedback   Methodology ·        Before any building started, I wrote a project brief and kept a running build-notes file, using Claude Cowork for both and updating them constantly while the actual coding happened in Claude Code. ·        Every decision, including scope cuts, tone rules, verification standards, ideas I rejected and why, was written down there and re-read at the start of each session, so nothing had to be re-argued twice. ·        The build itself ran in six numbered phases, each one ending with an explicit stop so I could look at it before the next started. Later refinements went into separate ".1" passes rather than quietly expanding a phase's scope mid-build. ·        The standing rule underneath all of it: no traditional Ba Zi claim ships without being checked against a real outside source, no matter how authoritative it sounds. ·        In practice that meant o  validating the calendar cycle of 55,152 consecutive days across 1900–2050 against an independently written formula anchored to a documented historical reference date, with zero mismatches; o  checking solar-term timings against the Hong Kong Observatory's published tables to the minute; o  validating the full engine end-to-end against a published, independently documented birth chart; and o  testing a core relationship table across all 100 possible stem combinations against a separate implementation. ·        That discipline caught real problems, including a widely repeated online source with a lookup rule inverted, a piece of "authoritative" advice I'd been given personally that turned out to be wrong, and an off-by-one error in an age calculation that testing alone wouldn't have surfaced. ·        AI built the app, but AI doesn't write the readings. Interpretations are assembled from rules against verified chart data, so nothing a user reads can be invented. ·        The app went live partway through the build, so every later improvement shipped automatically and got reviewed in its real environment. ·        Because the readings touch on personal things (weakness, missing elements, difficult periods), I wrote down explicit tone rules (state findings plainly, keep the framing warm, never diminish the person, no unexplained jargon) some of those are now enforced by automated tests.    Learnings ·        The most useful habit in this whole project was refusing to trust anything just because it ran without errors. Almost every real mistake I found came from deliberately cross-checking against a source, not from the code failing on its own. ·        AI will also confidently reproduce a common mistake if you don't check it, including its own past output. One real example was a reference document I wrote specifically to capture verified facts and stop future sessions re-deriving them turned out to contain the exact kind of error it existed to prevent, and it was only caught because a second AI session applied that same "check it against a real source" rule to the document itself. ·        Being non-technical wasn't a barrier to building this but it was a barrier to reviewing it properly, so the whole process had to surface decisions in plain language at the right moments rather than assuming I'd catch problems in the code. ·        Most of the real improvements in the finished app came from me questioning something I didn't understand and pushing back. ·        Tone turned out to need the same treatment as the calculations because I found that, left unspecified, generated copy drifts toward a recognizable machine voice, and writing the rules down (then testing against them) is what actually fixed it. ·        Small, frequent check-ins beat one big reveal at the end, since every phase review caught problems while they were still cheap to fix. ·        The part that seems likely to outlast this specific project is the discipline itself (i.e. the verification habit, the phased structure, the written decision log) rather than any particular tool.