From domain calculations to a complete AI planning product

It started with people. Then the question became timing.

For Johnny Kartakov, Arsum’s founder, Sidera’s origin goes back roughly a decade before this case study. The first question was not when to launch a product. It was how to understand the people he chose to work with. After business partnerships and other relationships that proved to be poor fits, he wanted a better framework for thinking about compatibility.

He describes a consultation with an astrologer as an early turning point. The description of him felt unexpectedly accurate to him, and that experience prompted years of study. He began exploring astrology in the context of relationships, business partnerships, and the different roles people take on. It was a personal practice long before it became a software product.

Over time, his attention shifted from who to when. In his own experience, some periods seemed to suit starting something new and pushing it forward; others felt better suited to finishing work, handling administration, reflecting, socializing, or resting. The question was no longer only how two people might work together. It was whether timing could become something a person could examine before making a commitment.

That shift supplied the product idea: turn those interpretations into a planning interface. The founder started with a basic calendar showing the method’s intensity and favorability scores. Instead of leaving someone with a long reading to translate into action, the calendar made dates and alternatives visible. A person could choose an activity, compare the product’s scores, and ask for more context before deciding. That became the connection between Sidera’s calendar, compatibility experience, and conversational AI.

These are the founder’s reported experiences and the motivation behind Sidera, not evidence that astrology can establish compatibility or predict an outcome. The distinction carries through to the product: Sidera presents its method’s calculations and interpretations, while the person retains the choice of whether and when to act.

Make a domain-specific method usable before a decision

Arsum developed Sidera as its own product, not as an external client engagement. The first serious version already brought together calendar, chat, and compatibility. Subscription monetization came later, after the founder saw commercial potential in the experience.

The initial focus was business timing: starting something new, launching a product, increasing visibility, or choosing a period for finishing and administrative work. The experience also extends to social activity, personal planning, and compatibility. A user can look at options, investigate the product’s reasoning, and make their own choice.

This is a case study of software engineering around an astrology methodology. The product’s scores express that methodology; they are not scientifically validated probabilities of business, relationship, or personal outcomes. That distinction matters when a numerical interface and fluent AI explanation appear together.

A calendar first, with conversation when detail is needed

A user supplies birth and location information, with a birth time when available. Sidera uses these inputs to present scored and highlighted calendar dates. Instead of starting with a long reading, the user can scan a month, compare options, and then explore a date through contextual chat.

The calendar and conversation serve different purposes. The calendar makes alternatives visible; chat helps unpack an interpretation, a chart combination, or another future date for the same activity. Compatibility adds a related workflow for romantic, friendship, family, and business contexts.

Arsum’s scope connected the calculation engine, backend APIs, React web application, Flutter Android application, onboarding, and these product surfaces. Building the surrounding application was as important as integrating a model: the user needs a way to enter context, navigate results, and return to a useful view.

Keep planetary data and domain rules outside the language model

The Python backend integrates Swiss Ephemeris for planetary-position data and applies implemented astrology rules, including Western and Vedic approaches. Arsum built the calculation and scoring logic around those foundations. Google location functionality helps users select the locations required by the product.

Missing birth time is handled with an explicit assumption: noon. That makes the flow possible without an exact time, but it does not establish that a noon-based chart is equally informative in every case. Input assumptions remain relevant to how a result should be interpreted.

During early development, calculation outputs were cross-checked against Astro.com, and the founder manually reviewed results across dates and refined compatibility behavior. These checks support the implementation process. They should not be read as validation of astrological predictions or as a formal evaluation of every AI answer.

Let the model interpret prepared context, not invent the calculation

The central architecture decision is the boundary between calculation and explanation. The backend prepares relevant astrological results and user context before passing selected information to the language model. The founder describes application-prepared context; direct calls from chat to the calculation engine were not established in the interview.

This gives each layer a defined responsibility. The calculation service produces domain results. The application selects the context relevant to the interaction. The model turns that context into a conversational explanation. The user can then explore the result without treating the conversation itself as the source of planetary data.

Separating these layers is a useful LLM application development pattern, but it does not guarantee that every explanation is correct. Calculation testing and generated-answer evaluation remain distinct engineering tasks. The interview established manual review, not a formal LLM evaluation dataset, hallucination benchmark, or model-change regression suite.

Own the product beyond the AI feature

Sidera runs in Docker containers on a VPS, with SQLite storage. Stripe supports subscriptions, Google Analytics supports product measurement, and the web and Android applications provide access to the experience. These are parts of one product scope, rather than evidence that a chat interface alone is ready for users.

Grafana and Loki provide operational visibility, Telegram carries alerts, and the founder monitors and responds to errors. This establishes an operating owner and a route for noticing failures after deployment.

Operational visibility and AI quality are different concerns. Logs and alerts can help investigate application failures; they do not, on their own, tell the team whether an interpretation was useful or well supported. The case does not claim formal service-level targets, automatic rollback, or per-answer AI quality monitoring.

Connect useful search answers to a personalized product

Distribution became part of the engineering work. The founder describes SEO as Sidera’s main acquisition channel, alongside social and community distribution. He emphasizes that the public content includes data from the application. The approach connects that product-derived information with indexable pages that answer a timing question before inviting the visitor into a personalized experience.

For a query such as when to start a business, the public page and the application answer different levels of the question. The page supplies an accessible starting point; the product adds personal inputs, calendar exploration, and contextual explanation. This creates a practical connection between application data, content, and onboarding.

A broad product creates a matching challenge. A business-timing visitor, a horoscope reader, and someone exploring compatibility may arrive with different intentions. Cohort-specific onboarding and better funnel measurement were active improvement areas at interview time, not completed conversion wins.

View full size

One product across calculation, AI, experience, and operations

Arsum built a functioning web and Android product with a calculation engine, planning calendar, contextual AI chat, compatibility, subscriptions, analytics, operational monitoring, and an organic acquisition system. The founder reports organic signups, trial activations, and paid subscriptions.

The strongest evidence is the shipped capability and the ownership around it. Traffic, conversion, retention, and revenue are not quantified here because the interview estimates were not accompanied by the analytics needed to substantiate them.

For founders commissioning AI product development, Sidera shows why the model is only one part of the scope. Domain logic, input assumptions, context preparation, product navigation, payment access, distribution, and post-launch response all need a place in the design. The transferable lesson is to define what the software calculates, what AI explains, and what remains a human decision.

Based on Arsum’s project interview and a review of the public website and signed-in application on September 6, 2026. Founder quotations were checked against the supplied reconstructed interview transcript; line wrapping is normalized and one excerpt trims an introductory phrase. They are Arsum’s founder describing his own product, not customer testimonials. This account distinguishes shipped capabilities, founder-reported adoption, and areas still requiring measurement.