Building ZodiacPlatform: A Full-Stack Astrology SaaS with AI and Wallet Workflows
18 Apr 2026
AISaaSNext.js.NETProduct EngineeringWallet System
A product engineering case study on building ZodiacPlatform with Vedic astrology workflows, AI chat, paid reports, wallet points, backend-owned business rules, and full-stack architecture.
Building ZodiacPlatform: A Full-Stack Astrology SaaS with AI and Wallet Workflows
ZodiacPlatform started as an astrology product idea, but the interesting part was not the horoscope content. The interesting part was turning a personal, emotional domain into a structured full-stack product.
The platform combines public discovery, birth profiles, Kundli features, AI chat, personality insights, Kundli matching, wallet points, and paid report workflows.
From an engineering point of view, it became a strong exercise in product architecture, user trust, backend-owned business rules, and AI-assisted personalization.

The product idea
The goal was to build something deeper than a generic daily horoscope page.
The product needed to support two modes:
- public discovery for casual users
- logged-in personalized Vedic astrology workflows for serious users
That meant the system needed:
- authentication
- saved birth profiles
- deterministic Vedic calculation data
- personalized dashboard
- AI chat
- wallet points
- paid feature access
- report workflows
- stable fallback behavior
- secure backend ownership of business logic
The product may feel spiritual to the user, but the engineering behind it has to be precise.
Public page and personalized dashboard
The public home page gives users a lightweight entry point: daily astrology, sign-based insights, compatibility entry points, and calls to action for personalized readings.
The dashboard becomes the logged-in user's astrology workspace.

It brings together:
- birth profile status
- wallet points
- personalized horoscope
- recent AI guidance
- quick access to major features
The dashboard is important because the platform has many modules. Without a clear home base, the product would feel scattered.
Birth profile as the source of truth
The birth profile powers most personalized features:
- horoscope
- Basic Kundli
- Detailed Kundli
- Life Analysis
- Personality Snapshot
- AI chat context
- Kundli Matching

This made the birth profile a critical domain object, not just a form.
One important product rule was to separate these states clearly:
- the user has no profile
- the profile exists
- the backend failed
- calculation is pending
- astrology data is incomplete
Those states should not be collapsed into one generic empty screen. In a trust-based product, wrong fallback behavior can make users think their saved data disappeared.
Kundli and deterministic calculation data
The Basic Kundli feature gives the user a structured chart snapshot from saved birth details.

For technical astrology fields, the system should use deterministic calculation data instead of random or generic text.
That matters for fields such as:
- Lagna
- Rashi
- Nakshatra
- Pada
- Atmakaraka
- Navamsa
- Dashamsha
Astrology interpretation can be narrative, but the calculation base should be consistent.
That distinction became one of the main architecture principles of the product.
Premium reports and long-form guidance
Detailed Kundli and Life Analysis were designed as premium report-style experiences.


The report experience needed to do more than list astrology labels. It had to explain what the result means, why it matters, and how a normal user should read it.
Life Analysis is more reflective and long-form.


The product direction was guidance, not fear. That tone matters in a domain where users may be emotionally invested in the result.
AI chat with wallet-aware usage
AI chat lets users ask questions about career, timing, relationships, finance, and life direction.

The important decision was not to make it an unlimited free chat.
AI chat is connected to wallet points so the product can control cost and abuse:
- show available points
- show cost per message
- check eligibility server-side
- deduct points server-side
- store transaction history
- fail safely when pricing or wallet state is unclear
The frontend can show the experience, but the backend must own wallet decisions.
That is non-negotiable in any paid product.
Kundli matching and compatibility reports
Kundli Matching uses two profiles and produces a compatibility report with score, Ashtakoota details, Manglik analysis, interpretation, and practical guidance.


The product should not reduce compatibility to a single number.
A score is useful, but the report should explain:
- what the score means
- which areas are strong
- where caution is needed
- what should be reviewed more deeply
This makes the feature more responsible and more useful.
Personality Snapshot
The Personality Snapshot feature turns technical astrology anchors into a more approachable user experience.

It uses saved birth details and Atmakaraka-related interpretation to present:
- core nature
- strengths
- work style
- emotional pattern
- relationship style
- growth advice
This kind of feature matters because it gives users a quick personal insight without overwhelming them with technical chart language.
Architecture behind the product
ZodiacPlatform was designed as a full-stack product:
- Next.js frontend
- ASP.NET Core backend API
- Firebase authentication
- PostgreSQL persistence
- backend-owned wallet module
- Proprietary based calculation service
- AI interpretation workflows
- server-side routes/proxy flows for sensitive calls
The mental model was:
Next.js frontend
-> server routes / proxy
-> ASP.NET Core backend
-> database, wallet rules, paid feature rules
-> calculation and AI services
The frontend owns the user experience.
The backend owns business rules, wallet safety, paid access, and trusted decisions.
That separation kept the product easier to reason about as features grew.
Shared contracts kept the product maintainable
As the platform expanded, repeated patterns started appearing:
- auth state
- wallet state
- pricing
- loading
- fallback
- cache invalidation
- paid feature access
- error handling
If every page solved those independently, the product would become inconsistent.
So the architecture needed shared semantics:
- no wallet deduction when eligibility is unclear
- no fake success after failed payment
- no frontend-only wallet mutation
- clear insufficient-points state
- clear backend-failed state
- route-owned shell for complex pages
These rules are not glamorous, but they protect user trust.
Future product directions
The platform has room to grow into:
- downloadable premium reports
- career and finance reports
- marriage compatibility reports
- numerology as a separate vertical slice
- report order history
- wallet-based bundles
- long-form AI-assisted guidance
The key is to keep each vertical as its own product slice while sharing auth, wallet, fallback, and reporting contracts.
That gives the product room to expand without turning the codebase into a tangle of special cases.
Engineering takeaway
ZodiacPlatform is a reminder that even a spiritual or content-led product needs strong engineering fundamentals.
The user may come for astrology guidance, but the system still needs:
- reliable authentication
- deterministic source data
- safe wallet behavior
- clear fallback states
- maintainable modules
- responsible AI usage
- trustworthy paid workflows
For me, the project became a full-stack product engineering case study: AI, SaaS, monetization, user trust, backend ownership, and frontend experience working together.
Related: