Veythar

Veythar isn't on my portfolio site yet, and I've been going back and forth on when it should be, because it's simultaneously one of the most technically rigorous things I've built and one of the least finished as an actual shippable product. Internally I've also called it Jyotish Studio while working on it ("jyotish" being the Sanskrit term for the astrology tradition it's actually implementing), but Veythar is the name I've settled on for the real, public version.

The idea is a local-first, offline, no-account, no-telemetry Vedic astrology and numerology platform, built two-sided. One side is genuinely professional-grade: full charting across the KP and Nadi systems, Parashari and Jaimini approaches, planetary sub-periods, sixteen divisional charts, strength calculations, compatibility matching, all the tools a real practicing astrologer would actually need, built to match or beat the commercial software that currently dominates that space. The other side is for everyone else: an AI layer over the same validated calculation engine that turns a birth chart into a plain-language report on personality, career, wealth, relationships, health, and a life timeline, exportable as a document with the actual chart images embedded, readable aloud by a synthesized voice, answerable through grounded conversation, and built to run entirely inside the browser, with no server, no API key, no data ever leaving the device.

Reverse-engineering the competition, on purpose

I studied the market leader in this space, a commercial tool called Horosoft, by working through thirty-eight screenshots of a licensed copy I kept strictly for study, and wrote an entire architecture-analysis document breaking down its feature set piece by piece before I designed my own. That's not a casual competitive glance. That's treating a rival product the way a real product team would: understanding exactly what the benchmark actually does before deciding what "better" would concretely mean, rather than guessing at what a professional astrologer's software needs to include.

The numerology engine has an unusually long provenance for a solo project: it started as a hand-built spreadsheet, got ported into a nearly thousand-line React component, then ported again into the TypeScript calculation engine that runs today. Three separate implementations of the same math, each one checked against the last before I trusted it. I also gathered thirty-five real, professionally written astrology reports, sourced with consent from my own site, specifically to have real ground truth for what the AI's generated writing should actually sound like, rather than guessing at tone from nothing.

What's actually validated, and what isn't yet

The calculation engine is the strongest part of this project by a wide margin, and I can say that with real evidence behind it, not just confidence. Cuspal sub-lord calculations match Horosoft exactly on every one of thirty-six test cases. Planetary sub-lords match on all twenty-one. Planetary positions land within roughly a minute and a half of arc. The daily almanac calculations match a well-known reference tool to within a minute. I ran the strength-ranking system against three well-documented real charts (Gandhi, Einstein, Princess Diana) as a sanity check, since their life outcomes are public and their charts are widely analyzed; the engine correctly ranked Gandhi's dominant planetary strengths seven out of seven times and Einstein's five out of seven, which is solid but not perfect, and I've said so in my own internal notes rather than rounding that up.

What isn't there yet, and what I've flagged plainly rather than let slide: the sixteen divisional charts calculate correctly at the sign level but don't yet compute the more advanced lagna-level detail a full professional tool needs. Sub-period dating hasn't been diffed against Horosoft the way the sub-lords have. The event-timing engine is currently heuristic rather than fully rule-based. Compatibility matching doesn't yet implement dosha cancellation, a real nuance professional astrologers apply. My own city database covers roughly two hundred locations, not the comprehensive global gazetteer a finished product would need.

The honest self-audit

I scored this project against myself, across the categories that actually matter for shipping something real: engineering quality around seven and a half out of ten, architecture the same, feature completeness at seven, confidence in the astronomical accuracy at eight. User experience I marked lower, around six and a half. And commercial readiness, whether I'd actually charge someone money for this today, I scored at five out of ten, and my own verdict alongside that number was blunt: approve it for a free public web beta, and nothing beyond that yet. Not paid, not enterprise, not installed on anyone's desktop.

That last part matters more than it might seem. The project folders are literally numbered as staged platform targets (web, then Windows, then the Play Store, then macOS, the App Store, Linux), laid out as a real, sequenced rollout plan. Right now, five of those six folders contain nothing but a README with build instructions. No installers. No signed binaries. No store listings. The multi-platform ambition is real and the sequencing is deliberate: web first, prove the product works, then expand outward. But I want to be completely clear that "multi-platform" describes the plan today, not the shipped reality. Reality is one working web app and five folders waiting their turn.

Why zero budget was a constraint, not an accident

No paid APIs, no paid data sources, anywhere in this build: a hard rule I set for myself from the beginning, both because I genuinely don't have a budget to spend on a side project and because it forced real engineering discipline I think the project is better for. Choosing an open-source ephemeris library over the more commonly used commercial one, specifically over licensing concerns, is one direct result of that constraint, documented in its own file rather than buried as an implicit choice nobody would notice. Running the AI layer as a small quantized model entirely in-browser, instead of calling a hosted API, is the same constraint applied to the product's most ambitious feature.

I'll close on the gap I think matters most, honestly: the calculation engine, the hard astronomy and math, is the part I'm most confident in. The interpretive layer, the actual astrological reasoning that turns a correct chart into meaningful guidance, is the least mature part of what I've built, and I've said so directly in my own status notes rather than let a working engine imply a finished product. Getting the math right was necessary. It was never going to be sufficient on its own.

Full stack developer. Founder of Yashveer Labs. The chart is accurate. The story it tells you is still the part I'm most honest with myself about not having finished.