Shipping a 60-year fasting calendar that works entirely offline

Most calendar apps are thin clients. They ask a server what today means, render the answer, and fall over the moment the user walks into a basement. For a fasting companion that is not an inconvenience — it is a failure. People check Viratham AI early in the morning, often on patchy rural networks, and the answer they need is binary: do I fast today or not?

So we set a rule before writing any code: the core answer must never require a network.

The problem with precomputing everything

A naive approach is to precompute every fasting day for every type and ship it as JSON. We tried it. Nineteen fasting types across sixty years, each with tithi boundaries, start and end times, and regional variants, produced a payload that was both large and impossible to correct — a single rule change meant regenerating and reshipping the whole table.

The insight was that fasting days are not arbitrary. They derive from a small number of astronomical primitives: lunar phase, solar longitude, and the local sunrise for the user's coordinates. Everything else is a rule layered on top.

What we actually ship

• A compact ephemeris table — lunar and solar positions sampled at a fixed interval, interpolated at runtime.
• A rules engine where each of the 19 fasting types is expressed declaratively, not as bespoke code.
• A local sunrise and sunset solver, so the same date resolves correctly whether the user is in Chennai or Chicago.

// Each fasting type is a rule, not a hardcoded list of dates.
const ekadashi: FastRule = {
  id: 'ekadashi',
  matches: (day) => day.tithi === 11,
  window: (day) => ({
    start: day.sunrise,
    end: nextDay(day).sunrise,
  }),
};

The result is a few hundred kilobytes instead of tens of megabytes, and a rule correction becomes a one-line change rather than a data migration.

Where the AI fits — and where it does not

Viratham AI includes a GPT-4o powered guide, and the temptation was to let the model answer date questions directly. We deliberately did not. Language models are excellent at explaining why a fast is observed, what the Katha behind it says, and what may be eaten. They are unreliable at arithmetic on calendars.

This is the pattern we now apply to every AI feature we build: the model is a language interface over a system of record, never the system of record itself.

What we would do differently

We under-invested in the localisation pipeline at the start. Supporting seven languages meant seven copies of every explanatory string, and early on those drifted out of sync. Moving to a single source language with a review queue for translations cost us two weeks we should have spent up front.