Menu in Hamburger Icon
Prashna Follow Up Screen
Prashna Screen
Dark Theme and Multilingual Features
Home Screen
Panchanga expansion
Special Reports
Marriage Compatibility Screen
Common Reports
Specific Area Reports

Jyotishya Viveka — An AI-Native Business Built by One Person with AI

Authentic Wisdom. Unbiased Guidance.

Inspiration

Jyotishya Viveka began with a simple question:

Could AI change not just how people find astrology guidance, but how the guidance itself is delivered?

The first generation of astro-tech made it easier to discover and connect with astrologers. But the underlying service model remained largely the same: one astrologer, one customer, one block of time.

That model creates barriers for both users and practitioners.

For users, exact historical birth details may not always be available. Some of the most important questions people want to ask — about relationships, money, career, family, fears, uncertainty, or deeply personal situations — may also be uncomfortable to discuss with another person. Traditional consultations require scheduling, trust, disclosure, and practitioner availability. That naturally makes astrology something many people use only for major life events.

Jyotishya Viveka was inspired by the possibility of removing those barriers.

Through Prashna, a user can begin with the question itself when exact birth details are unavailable. When birth details are available, the platform can use Janma / natal-chart-based workflows. The interaction can be private, conversational, multilingual, voice-enabled, and available whenever the user needs it.

There was also a second inspiration: the practitioner economics of the industry.

Astrology software has digitized chart calculation for years, but interpretation, explanation, follow-up, and customer interaction still depend heavily on human time. I wanted to explore whether AI could create leverage at the service-delivery level, not simply add a chatbot on top of an existing process.

The long-term thesis is:

The first generation of astro-tech digitized access to astrologers. Jyotishya Viveka aims to digitize the delivery capacity of astrology itself.

There was another problem I wanted to address too: the quality and depth of the actual guidance.

Many digital astrology experiences stop at short conclusions, generic statements, or a list of positive and negative indicators. Even when the underlying astrological reasoning is complex, the user often receives only the conclusion. That keeps the user dependent on the report rather than helping them understand why a particular interpretation was reached.

Jyotishya Viveka was designed to do the opposite.

The goal is not to expose raw implementation details or overwhelm users with calculations. It is to explain the meaning, reasoning, nuance, contradictions, strengths, cautions, and practical implications in clear customer-facing language. When different astrological factors point in different directions, the report should not simply hide the inconvenient parts. It should explain the tension and show how the final interpretation was formed.

Early user feedback has repeatedly highlighted the depth, detail, clarity, and thoughtfulness of the final reports as one of the aspects they value most.

I cannot objectively claim that no other product offers similar depth, but this level of explanatory quality is one of the differentiators I care about most.

But there is another part of the inspiration that became just as important while building the product.

I built Jyotishya Viveka single-handedly.

I had not done serious programming for approximately 16 years. I did not begin this project knowing Python, Node.js, Next.js, React, Supabase, Cloud Run, or most of the modern technologies required to build and operate the product.

There was no conventional development team helping me — no programmer, designer, DevOps engineer, product manager, or technical consultant. My development collaborators were LLMs.

That made Jyotishya Viveka an experiment at two levels:

Can AI fundamentally change the delivery model of a professional guidance service?
Can AI make it possible for one person without current professional programming skills to build that business from scratch?

For me, the answer to the second question became one of the most exciting parts of the project.

What it does

Jyotishya Viveka is a mobile-first, AI-native Jyotisha guidance platform.

Live product:

https://jyotishyaviveka.com/home

Instead of forcing every user to begin with a long birth-data form, the product is designed around the user's actual question.

A user can ask something specific such as:

“I have an important interview tomorrow. How should I approach it?”

Where appropriate, the Prashna pathway can work without requiring exact historical birth details. For users who have reliable birth information, Jyotishya Viveka also supports Janma / birth-data-based analysis.

The production experience includes:

question-first Jyotisha guidance
Prashna workflows
Janma / natal-chart workflows
deterministic astrology computation
contextual AI interpretation
follow-up conversation
multilingual interaction
voice-enabled input
reports
authentication and profiles
payment flows
mobile-first Progressive Web App support

The product follows an important architectural principle:

Calculation first. Interpretation second.

Generative AI does not calculate planetary positions or invent astronomical facts. Deterministic software performs the astrology calculations and generates structured Jyotisha context. AI then interprets that context, explains it naturally, and supports follow-up conversation.

Depth and transparency of the final guidance

A major product goal is to make the final output deep enough to be genuinely useful, but understandable enough to educate the user.

Instead of presenting a short verdict, the reports are designed to explain:

what the important astrological factors mean in the user's situation
where multiple indicators reinforce one another
where different indicators conflict or create nuance
why a conclusion is being drawn
what strengths and cautions coexist
what the interpretation means in practical, everyday language
what the user may want to pay attention to next

The intention is not to dump raw calculations on the customer. The intention is to avoid the opposite problem too: hiding the reasoning and giving only an unexplained conclusion.

This is particularly important in a knowledge-driven service. A good report should not merely tell someone what the system concluded; it should help them understand the structure of the interpretation.

Early users have specifically appreciated the level of detail and explanatory depth in these outputs, which has reinforced this as one of the product's most important differentiators.

Jyotishya Viveka also has a second production AI layer:

AI Business Operations Dashboard:
https://jyotishyaviveka.com/admin/business-ops

Structured business metrics are calculated by software and then supplied to Gemini. Gemini evaluates business health, interprets risks and anomalies, and recommends possible owner actions. The results are persisted and displayed in the administrator dashboard.

The simplest way to describe the operating model is:

AI helps deliver the service, and AI helps operate the business that delivers the service.

How we built it

Although this Devpost section is traditionally called “How we built it,” Jyotishya Viveka was, in practice, built by one human working with multiple AI systems.

A one-person AI-native development team

I had been away from serious programming for roughly 16 years.

When I started, I did not have working knowledge of the modern stack required for the product. Instead of spending months first learning every framework in isolation or assembling a conventional engineering team, I learned and built simultaneously by using AI as a set of specialized collaborators.

I used multiple LLMs for different types of work:

ChatGPT Plus for product thinking, business-model refinement, UX ideas, prompts, content, report design, debugging discussions, documentation, and problem solving.
OpenAI Codex as a coding agent working on implementation, debugging, refactoring, and technical tasks.
Gemini Pro through Antigravity as another coding and repository-aware development agent.
Gemini inside the production product for the Business Operations / FinOps AI workflow.

Rather than forcing a single model to do everything, I treated the LLMs more like different members of a virtual team.

Because Codex and Antigravity worked in separate environments and did not automatically share context, I introduced repository-based handoff files such as:

worklog-handoff.md
worklog-handoff-gemini.md

These files allowed one AI development agent to leave implementation context for another — effectively letting the agents “pass the baton” between development sessions.

The LLMs were my only development collaborators. I still made the product decisions, chose what to build, defined the Jyotisha methodology, evaluated trade-offs, tested the application, reviewed outputs, decided priorities, and approved what went into production.

Technical architecture

The production system combines:

Next.js / React for the application
Vercel for frontend and web/API hosting
Supabase for authentication and database services
Python FastAPI for backend services
Google Cloud Run for backend execution
Google Cloud Scheduler for recurring operational workflows
Swiss Ephemeris (pyswisseph) for deterministic astrology computation
OpenAI for most real-time customer-facing AI interpretation
Gemini (gemini-3.1-flash-lite) for AI Business Operations
Razorpay for payment flows

For customer guidance, deterministic software first generates structured astrological data. OpenAI then performs the language and interpretation layer.

For Business Operations, deterministic software gathers and calculates usage, revenue, provider-cost, token, and related operational metrics. Gemini then performs the judgment-oriented layer — evaluating business health, risks, trends, anomalies, and recommended actions.

The domain was acquired on July 6, 2026, development accelerated through July and August, and the public production product launched on August 14, 2026.

That short build period matters to me because this was not the work of a hidden development team. It was one person learning, deciding, testing, and coordinating multiple LLMs to get from an idea to a live production system.

Challenges we ran into

1. Building modern software after a 16-year programming gap

The first challenge was simply the scale of what I did not know.

Modern frontend frameworks, cloud deployment, serverless architecture, authentication systems, database security, APIs, Python services, Node.js tooling, CI/CD, payment integrations, LLM APIs, and production observability were not technologies I had been actively programming with.

AI made the project possible, but it did not remove the need to understand what was happening.

I had to learn how to ask better questions, evaluate proposed solutions, test code I had not personally written line-by-line, recognize when an agent was making a wrong assumption, and decide when one model's approach was better than another's.

The challenge shifted from “Can I personally write every line of code?” to “Can I direct, verify, and integrate the work well enough to build a reliable system?”

That was a completely different development skill.

2. Separating deterministic truth from generative interpretation

Astrology contains a substantial computational layer.

It would have been easy to send a birth date and question to an LLM and ask it to generate an answer. I did not want to build the product that way.

Planetary positions, charts, time/location calculations, Vargas, and structured rule execution need deterministic computation. Generative AI is much better suited to interpretation, explanation, conversation, and synthesis.

Establishing that boundary became a foundational design decision:

Deterministic software establishes the structured facts. AI interprets them.

3. Producing deep reports without producing unreadable reports

Another challenge was the quality of the final guidance itself.

Jyotisha can contain many interacting factors, and simply exposing all of them would create a technically dense report that most customers would not want to read. But compressing everything into a few generic statements would lose the very depth that makes the analysis valuable.

I had to keep refining the product so that the report could preserve nuance, contradictions, supporting factors, cautions, and reasoning while still reading like a customer-facing explanation rather than an internal calculation sheet.

That distinction became important:

Do not hide the reasoning — but do not make the customer read the machinery.

The final report experience therefore aims to explain the astrological logic and significance without exposing unnecessary implementation detail, validation traces, or raw computational output.

4. Coordinating multiple LLM development agents

Using multiple AI agents increased development speed, but it also created context fragmentation.

One coding agent might understand a bug that another had never seen. One might refactor a service without the other knowing why. Long-running development also exceeded what could safely live in a single conversational context.

The repository handoff files became a simple but important solution. They gave the AI agents a persistent place to describe what had changed, why it had changed, and what still needed attention.

That taught me that multi-agent development requires process and documentation just as human teams do.

5. Making Gemini a real production workflow

I did not want Gemini to appear in the project only as a competition checkbox or a one-off demo call.

The Business Operations workflow had to behave like a production service: scheduled execution, manual execution, persisted results, run history, timestamps, model metadata, success/failure status, and an administrator-facing dashboard.

Some early runs failed before later runs succeeded. That was useful. It forced me to treat the AI workflow as an observable production system rather than an invisible API call.

6. Understanding the economics of an AI-native business

AI costs are unusual because provider billing, prepaid credits, API consumption, subscriptions, infrastructure invoices, and token telemetry are not always expressed in the same way.

I had to distinguish funding from consumption, reconcile different providers, and avoid treating unavailable data as if it were zero.

That challenge is one reason the FinOps / Business Operations layer became part of the product.

7. Privacy

Jyotishya Viveka can handle questions that are deeply personal.

That meant privacy could not be treated as a final compliance checkbox. Competition evidence, logs, screenshots, and documentation needed to prove that the product was running without exposing customer names, phone numbers, email addresses, birth details, or private questions.

For this product, privacy is not merely defensive.

For some users, privacy may be what makes the consultation possible in the first place.

Accomplishments that we're proud of

The accomplishment I am most proud of is that I actually got this into production single-handedly.

I started without a current professional programming background, after roughly 16 years away from serious coding, and without knowing most of the modern technology stack I would eventually use.

Yet in a very short period I was able to build and launch a system containing:

a live mobile-first PWA
authentication and user profiles
deterministic Jyotisha computation
Prashna workflows
Janma-based workflows
conversational AI
multilingual interaction
voice-enabled input
reports
payment flows
a Python backend
Supabase
Vercel
Google Cloud Run
scheduled jobs
production FinOps
and a Gemini-powered Business Operations dashboard

I did this without a conventional human development team. LLMs were my development collaborators.

That is the part that feels most innovative to me.

A project of this breadth would previously have required me either to spend a long time retraining as a full-stack developer or to assemble people covering product, frontend, backend, cloud, AI, design, documentation, and operations.

Instead, AI allowed me to coordinate many of those capabilities myself at comparatively low cash cost and in a compressed timeframe.

I am also proud that the product is not simply an LLM wrapper.

The deterministic-versus-generative separation is deliberate. The user-facing AI is connected to structured Jyotisha computation. Gemini is connected to an actual Business Operations workflow. The system has distinct AI and non-AI responsibilities.

Another accomplishment I care deeply about is the quality of the final reports.

I wanted the output to feel less like a generic horoscope and more like a thoughtful consultation: detailed, internally coherent, willing to explain mixed signals, and willing to tell the user why a conclusion was reached. The system is designed to surface nuance rather than quietly discard inconvenient or contradictory indicators.

Early users have repeatedly appreciated the depth and level of explanation in the reports. I do not treat that as proof that the product is objectively better than every alternative, but it is strong validation that the design goal — deep analysis explained transparently in user-friendly language — matters.

I am especially proud of this progression:

AI helped me conceive the business.
AI helped me build the software.
AI helps deliver the customer experience.
AI helps operate the production business.

For me, that is a much more meaningful definition of an AI-native business than simply adding a chatbot to an existing product.

Most importantly, this project made something possible that, for me personally, would have been effectively impossible to execute alone in this timeframe only a few years ago.

What we learned

The biggest lesson I learned was not Python, Node.js, Next.js, or any individual technology.

It was how to build with AI when I did not already know those technologies.

I learned that the valuable skill is increasingly not just writing syntax from memory. It is being able to:

define the problem clearly
decompose it
give AI enough context
challenge its assumptions
test what it produces
compare different approaches
preserve context between agents
recognize when an output is plausible but wrong
and retain human ownership of the final decision

I also learned that AI-native is a business-model decision, not a chatbot feature.

The important opportunity is not merely faster content generation. AI can change the fulfilment economics of a service. If software can handle many customer interactions concurrently, service capacity is no longer directly proportional to practitioner hours.

Another important lesson was that deterministic systems and generative AI are stronger when each is used for what it does best.

Deterministic code is better for repeatable calculations, accounting, structured rules, and auditable facts. Generative AI is valuable for interpretation, explanation, conversation, synthesis, and decision support.

I learned that privacy can also create access rather than simply protect it. A person may ask an AI system something they would hesitate to disclose to another human.

And I learned that AI systems need operational discipline. If AI is running production workflows, then cost, execution history, errors, latency, provider usage, and business impact need to be observable.

Finally, I learned how much leverage AI can give one determined person.

AI did not remove the human role. It changed it.

I spent less time trying to personally be every specialist and more time acting as the product owner, orchestrator, reviewer, tester, domain expert, and decision-maker across a virtual team of AI capabilities.

What's next for Jyotishya Viveka

The immediate focus is to improve the direct-to-consumer product: better guidance flows, stronger multilingual and voice experiences, richer reports, better observability, and disciplined unit economics as usage grows.

A major part of that work will be continuing to improve report depth, transparency, and explanatory quality. I want the system to become even better at showing users how important factors fit together, especially when the interpretation is mixed or nuanced, without turning the experience into a technical textbook.

The goal is not only to give users guidance. It is to help them gradually understand the logic behind that guidance.

I also want to make Jyotishya useful not only for life's largest questions but for smaller everyday decisions.

Traditional consultation friction naturally makes astrology episodic. If guidance is already available on a phone, a user can ask smaller questions more frequently. That creates the possibility of moving from an occasional consultation toward a recurring decision companion.

A major future direction is a B2B / white-label model for astrologers.

The goal would not be to erase practitioners. It would be to give them leverage.

A practitioner could potentially retain their own:

brand
methodology
interpretive style
customer relationship

while shared infrastructure handles:

deterministic computation
AI execution
knowledge delivery
reports
conversational interfaces
and operational tooling

That could let practitioners serve substantially more customers without consultation hours increasing proportionally.

The long-term opportunity is therefore two-sided:

make Jyotisha more accessible, private, conversational, multilingual, and convenient for users
give practitioners a new way to scale their knowledge and practice

But the biggest thing I want to continue exploring is broader than astrology.

Jyotishya Viveka showed me what becomes possible when one person treats AI not as a single tool, but as an extension of the team they do not have.

AI made it possible for me to build something I could not realistically have built alone, with my existing technical skills, in this amount of time.

That experience is now part of the product's story — and part of what I believe AI-native entrepreneurship can become.