Whatever a chart is taken to mean, producing one correctly is arithmetic: planetary positions from an ephemeris, a house division, an ayanamsa where the tradition uses one, and a birth moment resolved to the right place and the right historical time zone. We build that layer so it can be checked against published references, along with the consultation, content and subscription product that sits on top of it.
A chart is only as good as the moment it is cast for. Local time before standardisation, wartime clock changes, disputed daylight-saving history, and coordinates given as a place name rather than a position will each move a house cusp. The system needs a resolution path that records its assumptions instead of quietly defaulting.
Users compare output against ephemerides, almanacs and other software, and a discrepancy in the last minute of arc becomes a support ticket. Calculations need a reference implementation to test against and a stated precision, so a difference can be explained rather than argued over.
House systems, zodiac conventions, ayanamsa variants, node definitions and dignity schemes differ between traditions, and between practitioners within one tradition. These are configuration rather than forks, and the engine has to carry the choice consistently through every derived calculation.
Daily transits for a large user base, panchang for every location and charts generated on demand add up to a great deal of repeated arithmetic. Precomputation, caching keyed on the inputs that genuinely change the result, and cheap invalidation are what keep response times and hosting costs sensible.
The commercial side is a scheduling problem across time zones, covering practitioner availability, rescheduling, recordings, follow-ups and refunds. It is ordinary software, and it is usually where a platform built around an impressive calculation engine turns out to be thin.
The calculation layer has to be right, because everything downstream inherits it. Positions come from an established ephemeris rather than an approximation, and the engine states its precision, its epoch handling and its treatment of the awkward cases: retrograde stations, near-cusp placements, high latitudes where several house systems degenerate, and dates outside the range the source data covers.
We build it with a suite of known charts checked against published values, so a change to the engine cannot silently move an answer. Where two traditions legitimately differ, the system produces both under an explicit setting rather than picking one and calling it correct.
Most of the build is not astronomy. It is accounts, saved charts for family and clients, diary management across time zones, subscription tiers and what happens at the end of one, report generation in more than one language, and an API other applications can consume without exhausting the calculation capacity.
That part is ordinary engineering and benefits from being treated as such. Entitlements decide what an account may generate, caching decides what it costs to serve, and the calculation engine sits behind an interface so it can be improved, replaced or run separately without the product being rewritten around it.
The engine comes first and is validated on its own, against reference charts, before any interface depends on it. Doing this early prevents the expensive version of the problem: a platform already in production whose numbers are being questioned, with no way to distinguish an engine fault from a configuration difference.
The consumer product follows, covering chart generation, saved charts and reports, with the commercial layer after it. A public API, where one is wanted, comes last, because rate limiting, versioning and support obligations to third-party developers are commitments more easily made once the calculation behind them has settled.
An established one rather than an in-house approximation, chosen for the date range, precision and licensing a given product needs. The choice is recorded and the engine states the precision it offers, so output can be reconciled against other software instead of simply differing from it.
Yes. Zodiac convention, ayanamsa, house system, node definition and aspect rules are configuration carried through the calculation, so one engine serves both. Where the traditions genuinely disagree, the setting is made explicit rather than chosen on the practitioner’s behalf.
The uncertainty is recorded rather than hidden. A chart cast from an approximate time is marked as such, and the interface can show which placements are sensitive to that margin, so a practitioner knows where a rectification would change the reading.
Yes, with versioning, authentication, rate limiting and per-key quotas, because calculation is the expensive resource. Caching on the inputs that determine a result is what makes a public API affordable to run at any real volume.
Yes. Scheduling across time zones, practitioner availability, sessions, subscriptions and entitlements are usually a larger part of the work than the chart engine, and they are also where an otherwise accurate platform tends to be weakest.
Share the workflows, records, exceptions and integration boundaries the system needs to support. We will help define the technical scope.