# Build brief — a focused alternative to Dreams & Stars > **Verdict:** Partly, if you narrow it · **Buildability:** 58/100 · **Category:** Wellness > **Source:** https://www.canitbevibecoded.com/dreams-and-stars > Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Dreams & Stars. Verify current pricing and capabilities before acting. ## Context **Dreams & Stars** — AI dream interpretation and natal-chart astrology readings, three-layer analysis in Turkish and English. The reading loop itself · collect a dream or birth details, prompt an LLM, stream back an interpretation · is a focused build with any modern coding agent. What resists cloning is the boring half: real natal-chart math from ephemeris data rather than an LLM guessing planetary positions, a prompt methodology (Jungian + Ibn Sirin + actionable layers) tuned over real usage, a budget-reservation system that stops one runaway API call from burning the month's margin, and the credits/payment plumbing. Build the personal version for your own dream journal, but don't expect the DIY build to hold up as a product. This brief describes a focused, single-operator replacement for the part of Dreams & Stars that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest. ## What you are building Take a dream description or birth date/time/place, calculate a real natal chart from ephemeris data for astrology, run it through a structured system prompt, and stream back a bilingual interpretation. - Log workouts and nutrition, track trends, and keep personal health data exportable. - A responsive interface with real empty, loading, success, and error states. ## Requirements ### Functional - An ephemeris library for real planetary positions (Swiss Ephemeris bindings), not LLM-guessed astronomy. - A database for reading history and credit balances. - Stripe or RevenueCat if you want to charge for it. ### Data and integrations - Anthropic or OpenAI API key. Each of these needs a real account, credential, or quota. Set them up before writing feature code. ### Non-functional - Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support. - Security: server-side secrets, validated input, and no credentials in the client bundle. - Reliability: retries with backoff on external calls, and a clear failure state when a provider is down. - Portability: the operator can export their data and leave without losing it. ## Implementation brief Build me a personal dream-and-astrology reading app to replace Dreams & Stars. - Next.js 14 App Router + TypeScript + Tailwind, one Postgres database (Supabase or local Postgres). Don't offer alternative stacks. - Two flows: (1) paste a dream description, (2) enter birth date/time/city for an astrology reading. - For astrology, install a Swiss Ephemeris TypeScript wrapper (e.g. swisseph-js/swisseph) and actually calculate Sun/Moon/Rising, planetary positions and major aspects from real ephemeris data · never let the model guess planetary positions. - Write one system prompt per flow. Dream prompt produces three sections: a psychological read (Jungian archetypes, shadow work), a traditional read (folk/Islamic symbolism, framed as interpretation not fortune-telling), and one practical suggestion. Astrology prompt synthesizes the Big Three, then current transits, in that order. - Call Anthropic or OpenAI with streaming; render the response as it arrives. - Store every reading (input, output, timestamp) in one `readings` table keyed to a local user id · no auth provider needed for personal use. - Look up birth-place lat/lon/timezone with a free geocoding API (e.g. Nominatim) · don't hardcode a paid geocoding vendor. - Support English and Turkish: pass a `language` param into the system prompt and instruct the model to answer entirely in that language, including headings. - No payments, no credits system, no rate limiting · this is for one person to use for free. Cap output tokens per call so a bug can't run up a large bill. - Add a simple history page listing past readings. - .env holds the LLM API key only. No telemetry, no analytics, no third-party scripts. - Out of scope, on purpose: multi-user accounts, credits/payments, compatibility/synastry readings between two people, a mobile app, and SEO content · those are the parts that turn a personal tool into a product. ## Delivery standard - Inspect the repository first, then write a short implementation plan before writing code. - Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data. - Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations. - Include responsive layouts plus genuine empty, loading, success, validation, and failure states. - Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data. - Add structured logs around every external call and return actionable errors without leaking sensitive details. - Write unit tests for the core logic and one automated test of the main user journey. - Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations. ## Acceptance criteria - [ ] A clean install starts the app using only the README and .env.example. - [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable. - [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state. - [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control. - [ ] Tests, type checking, linting, and a production build all pass with no ignored failures. - [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified. ## Non-goals Do not build these, and do not claim to have replaced them: - The three-layer interpretation methodology (psychological/Jungian, Islamic/Ibn Sirin traditional, actionable) tuned over real usage, not a first draft. - Real natal-chart accuracy from ephemeris data instead of an LLM approximating planetary positions. - A spend-reservation system that caps provider cost before generation starts, so one bad request can't blow the budget. - Native-quality bilingual Turkish/English copy, not machine-translated. - The credits/paywall, Stripe and RevenueCat payment plumbing. ## What you still own after launch - Secure credentials, rotate secrets, and handle provider rate limits. - Run migrations, backups, restores, and dependency updates. - Test the critical journey after every model, API, or hosting change. - Monitor failures and fix the edge cases a first prompt will miss. ## Risk **Operational risk.** The code is achievable; dependable data, integrations, and ongoing operations are the real cost. Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet. ## Existing alternatives Before building, compare these checked options: - [Astro-Seek](https://astro-seek.com) — Free natal chart calculator and traditional interpretation, no signup · real astronomy, no AI narrative - [DreamMoods](https://www.dreammoods.com) — Free dream symbol dictionary running since the late 1990s · lookup-based, not a personalized AI narrative ## Prior art Working open-source software you can read, fork, or borrow from before starting: - [swisseph-js/swisseph](https://github.com/swisseph-js/swisseph) — Type-safe TypeScript wrapper for Swiss Ephemeris · the real astronomical calculations behind any honest natal chart --- Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/dreams-and-stars