The builder’s guide

Astro Chanakya — a disciplined guide to building the product and company

Prepared 25 October 2026. Planning window: 2 November 2026–30 January 2027, followed by conditional milestones through October 2027.

My recommendation: introduce AI as an explanation layer over your existing product, and validate a focused paid experience before building a general AI astrologer. The first release should let someone open their existing report, ask a relevant question, understand the answer's chart basis, and leave with a useful explanation. A credible starting proposition is: “Understand your kundli and the traditions around your important life events, in language you understand.”

Your concern about anyone having access to an LLM is correct. A chat interface, an elaborate prompt, and access to a chart library are readily reproducible. A business becomes harder to displace when it consistently serves a particular customer better, earns distribution, maintains dependable quality, and develops a history of useful customer interactions. Those advantages have to be demonstrated; calling the engine proprietary does not establish them.

You have already built substantially more than a concept. You confirmed daily predictions, birth-time-and-place-based jataka readings, reports, auspicious daily timings, business and marriage predictions, ceremony timings, and web, Android, and iOS apps. This plan builds on those assets. It does not recommend rebuilding the apps. User counts, payment history, actual engine implementation, operating costs, and founder availability remain unspecified. The schedule assumes approximately 50 combined founder hours per week and access to a part-time domain reviewer. If capacity is lower, extend dates and preserve the quality gates.

The recommendations below distinguish public observations, company claims, your reported capabilities, and proposals to test. I reviewed public product pages and current primary sources; I did not audit your source code, execute purchases at competitors, inspect your analytics, or validate anyone's predictive accuracy. Astrology should be presented as a traditional interpretive practice. Correct astronomical calculations do not establish that an interpretation predicts life outcomes.

1. The strategic decision you and your friend need to make#

There are three different businesses hidden inside “Astrotalk with AI.” Choose deliberately.

AI is useful here because people often cannot ask follow-up questions of a static report. It can explain terminology, connect a relevant computed factor to a question, remember the immediate discussion, and switch into a supported language. It should not invent chart facts, manufacture certainty, or act as the decision-maker for someone's marriage, health, finances or career.

The first product question is: “Will people choose and pay for our way of understanding their chart over the alternatives they already use?” The second is: “What brings them back after their initial question is answered?” Resolve them separately. A profitable occasional-use report business is a valid outcome even if a subscription is not.

2. What the competitive research changes#

Do not treat similarly named domains as the same company: this report's Astrotalk comparison refers to astrotalk.com. Smaller AI competitors above demonstrate feature availability; they are not presented as proven business successes.

There is also evidence beyond astrology. RevenueCat's 2026 report covers more than 115,000 revenue-generating subscription apps using its platform, with eligibility thresholds. It reports median first-year revenue per payer of $30.16 for AI apps versus $21.37 for non-AI apps, but lower twelve-month retention for monthly plans: 6.1% versus 9.5%. These are broad observational benchmarks, not India-specific astrology forecasts or causal effects of adding AI. RevenueCat methodology and results

An August 2026 RevenueCat analysis of 3,519 AI apps found a particularly large gap at the first monthly renewal: 57.9% for its high-retention group versus 30.2% for its low-retention group. The study groups subscriptions by duration and follows eligible paid cohorts for a year. The useful implication is to examine what value appears before renewal; copying an associated price or trial structure does not guarantee that result. AI app retention study

Decision: AI can help you acquire a first purchase. Build the roadmap around usefulness, repeat demand and contribution after costs, rather than assuming novelty will sustain a subscription.

3. Start with a particular person and situation#

Keep 25–34-year-olds in India and one diaspora market as the initial audience, but define the customer by a situation as well as age. Younger users do not automatically have greater lifetime value. You need observed repeat usage, purchases and delivery costs over comparable periods.

The recommended first situation is a person encountering kundli or dosha questions while considering a relationship or marriage, who wants an understandable explanation of their own report. This uses your existing marriage reports, dosha tools and planned education content. It is a hypothesis about willingness to pay, not a claim that marriage is every user's priority.

For the diaspora pilot, select the country where you can recruit actual users and get feedback. If neither founder has a stronger network elsewhere, use the US as the provisional test market. Ten engaged users you can learn from are more useful initially than a theoretical global audience. Measure country of residence separately from language and birth country.

Start the AI release in English and one Indian language that a reviewer can assess competently. Your existing apps can retain their other supported languages. Expand AI language coverage only after it passes the same checks; translation fluency alone is insufficient.

Test this landing-page draft:

Your kundli, clearly explained.

Explore the chart factors behind your relationship questions, understand the terms in your report, and ask follow-up questions in your language.

Open my chart

Show “AI-generated explanation” within the answer experience and explain the calculation method. Sell the result the user wants to understand. Do not make “powered by AI” the entire value proposition.

4. What could become defensible—and what probably will not#

At the beginning, these are potential advantages, not existing moats. The engine is valuable infrastructure; if it is largely standard ephemeris calculations, competitors can obtain similar infrastructure. The advantage would come from its tested integration, interpretation quality and user experience.

Raw chat logs are not automatically a valuable dataset. They may contain private information, incorrect assumptions and reassurance-seeking rather than evidence of usefulness. Retain only what is justified and permitted; turn selected, appropriately consented examples into labelled quality cases. Do not silently repurpose intimate questions for training.

A useful improvement cycle is: observed failure → classified cause → corrected calculation/rule/interface → regression case → measured improvement. A larger pile of transcripts without this process is a storage burden.

Treat prompts, many AI personas, an “AI” badge, generic horoscope text, and five languages without reviewed quality as features competitors can reproduce. Fine-tuning a model also does not create defensibility unless it produces a measured advantage that customers value.

5. The first AI experience: explain the report already in front of me#

Avoid making the first screen an empty chat box. Start at the user's existing result.

1. Confirm the chart. Birth date, place, time confidence and calculation settings are visible and editable. Ask whether the time is exact, approximate or unknown.
2. Show an understandable summary. Explain three relevant factors from the existing report. Offer a clearly labelled sample before requiring sensitive details.
3. Offer contextual questions. For a marriage report: “What does this term mean?”, “Which chart factors were considered?”, “Do any cancellation rules apply?”, and “What changes if my birth time is approximate?”
4. Give a concise answer with expandable detail. Direct response, relevant calculated factors, traditional interpretation, limitations, and one useful next step.
5. Allow correction. The user can flag an incorrect fact, an unclear explanation, an unsettling answer, or a technical failure.
6. Offer a bounded purchase. An enhanced topic explanation and a clearly stated number of follow-up answers. Show a sample and exact contents.
7. Offer an optional reason to return. A weekly reflection or a saved planning task, depending on what the person actually used. Do not enroll them automatically.

Start with three supported intents: explain a chart/report term, explain a supported relationship/dosha rule, and explain a relevant current period already computed by your engine. Route unsupported requests to a helpful scope explanation or the existing appropriate tool. Add ceremony planning only after confirming that the necessary deterministic calculations are reliable.

Example answer style—not a reading for a real person:

Your report is flagging a Mars placement under the method selected for this chart. That does not establish that a relationship will fail. Open “Why this appears” to see the actual placement, the reference point used, and the cancellation checks performed. If your birth time is approximate, some of those checks may change. The report can help you understand the tradition; your relationship decision should also consider your experiences, values and conversations with your partner.

The actual product must insert verified factors from the engine, not this generic example or invented placements. If a cancellation rule is unsupported or ambiguous, state that rather than claiming it was checked.

The paid value must exceed today's free report. Possible additions are a carefully structured topic explanation, answers tied to specific report passages, uncertainty handling, a saved summary, and limited follow-up. Merely converting your existing free PDF into longer AI prose is weak differentiation.

6. The architecture: calculations, interpretation and conversation have different jobs#

Use your existing calculation service as the starting point. Do not let the language model calculate planetary positions, infer an ascendant from memory, or make up a dasha timeline.

flowchart TD
  A[Birth details and time confidence] --> B[Validated location and historical timezone]
  B --> C[Existing calculation engine]
  C --> D[Versioned chart facts and uncertainty]
  D --> E[Reviewed interpretation rules]
  Q[User question] --> R[Intent and scope checks]
  R --> E
  E --> F[Small evidence packet for the question]
  F --> G[LLM explanation in a supported language]
  G --> H[Fact, scope and output validation]
  H --> I[Answer with expandable basis]
  H --> J[Safe fallback or retry]
  I --> K[Optional feedback and consented memory]

Use a controlled workflow with a small set of read-only tools. Anthropic's architecture guidance recommends starting with the simplest adequate approach and distinguishes predictable code-directed workflows from autonomous agents. The proposed astrology workflow is my application of that principle; it does not need a group of autonomous agents for each answer. Architecture guidance

For a two-founder team, a modular application, existing engine service, ordinary database and background job queue should be sufficient initially. Keep calculation, rules, model adapter, billing and evaluation code separated within that system. Avoid a microservice migration or replacing your current stack merely because AI is being added.

A minimal answer contract should include:

chart_id, chart_version, engine_version, rules_version
question_id, intent, language, relevant_date_and_timezone
birth_time_confidence, calculation_settings
facts_used: [{fact_id, value, units_or_date_basis}]
rules_used: [{rule_id, tradition, reviewed_source_id}]
answer_sections: {direct_answer, interpretation, limitations, next_step}
validation_status, model_version, prompt_version
cost, latency, charge_status

Keep raw identity and birth details outside generic analytics. Render numerical chart facts and the “why” panel directly from trusted structured data where possible. Check generated dates and placements against that data. A source identifier is useful only if the claim actually follows from it; valid-looking identifiers alone do not prevent hallucinations. Add expert sampling and semantic checks for prose that cannot be verified mechanically.

Interpretation library: begin with roughly 20–30 reviewed explanations covering the chosen journey. Each entry needs its tradition, calculation prerequisites, conditions, exceptions, limitations, source rights, reviewer and version. Encode computational conditions in code. Store explanatory passages as curated content. If two traditions disagree, label the choice; do not average their conclusions into an unexplained score.

Retrieval can supply those passages to the model. A vector database is optional; a small labelled library can initially be retrieved by topic and rule IDs. Do not ingest random internet astrology articles as an authoritative corpus. Use owned, licensed or otherwise appropriately usable sources and record provenance.

Model selection: test two or three suitable hosted models on the same held-out cases. Compare correctness, language quality, instruction following, response time and cost per accepted answer. Select the least expensive option that passes your quality requirements. A stronger model can handle documented difficult cases; a cheaper fallback must pass the same scope checks before use. Avoid training a foundation model or fine-tuning before the evaluation set shows a recurring problem that simpler changes do not solve.

Memory: store only user-approved contextual facts, such as preferred language or a ceremony date they are planning. Show an editable “what we remember” view. Never convert an AI interpretation such as “you struggle with commitment” into a stored fact about the user. Changing birth details must invalidate dependent calculations and explain why earlier answers may differ.

7. Audit these foundations before exposing paid AI answers#

Your current breadth increases the importance of consistency across pages and apps.

The Swiss Ephemeris publisher describes AGPL and professional licensing alternatives and says the choice is required before a public service using the software is activated. Since a page names it and your product is already live, verify the actual dependency and applicable licence now, including wrappers and server use. This is an inventory task, not an assumption that you are currently noncompliant. Publisher's licensing documentation

For birth-time processing, use historical timezone rules rather than the current offset of the place. IANA maintains historical civil-time and daylight-saving data; preserve the timezone database version used for a calculation. IANA timezone database

Specific edge cases to support include ambiguous repeated times at daylight-saving transitions, nonexistent local times, similarly named towns, changes of birth date across UTC, southern-hemisphere locations, boundary positions, and times near a sign or nakshatra change. If only a birth-date range is known, even a Moon-sign conclusion can be uncertain near a boundary. Do not promise all non-ascendant results stay correct regardless of birth time.

For ceremony planning, separate the birth location/time from the event location/date/timezone. The engine should return eligible windows and applied rules. The LLM can explain or compare those windows; it must not generate auspicious times itself. Show dates with local timezone labels and revalidate before a saved event approaches, especially if timezone rules change.

8. Define quality before calling the AI ready#

Use three separate meanings of “accuracy”:

None of those independently demonstrates that astrology predicts future events. Do not market a computational pass rate or favourable feedback as “95% prediction accuracy.”

Start with a small evaluation set during discovery, then expand it as scope grows:

The final three rows form a proposed 150-case answer suite. Reserve approximately 20% as held-out cases, keep them out of prompt examples, and test some repeated runs because model outputs vary. Do not split very similar paraphrases between development and held-out cases and then claim independent generalization.

For reference charts, define numerical tolerances with the reviewer for each calculation and reference source. Matching a second product with different ayanamsa or node settings is not a meaningful test. A second wrapper around the same underlying engine may share its errors. Include independent boundary checks and invariants, not just screenshots from another app.

Have a domain reviewer assess rule fidelity and a second reviewer adjudicate disagreements on ambiguous cases. A bilingual reviewer checks each launch language. LLM judges may assist triage but should not be the sole source of truth. Anthropic's evaluation guidance describes combining code, model and human grading; the case design above is specific to this proposed product. Evaluation guidance

Proposed release requirements, to be agreed before viewing results:

• All critical calculation regression cases pass the declared tolerances; known boundary disagreements are explained or the affected feature is disabled.
• No observed unsupported placements, fabricated period dates, privacy breaches or critical harmful answers in the release suite. This is a release condition on that suite, not a claim of zero production risk.
• At least 90% of supported answer cases meet every material rubric requirement, including usefulness and rule fidelity. Report the numerator and denominator, plus failures by language and intent.
• The user can flag, delete, correct and obtain an appropriate credit reversal for a failed paid response.
• Set a provisional p95 completed-answer target of 15 seconds and a hard timeout; measure it on realistic devices and connections. Adjust based on user testing, not guesswork.

Block an affected feature if it fails a critical condition. Repair and rerun its regression cases before expansion. A persuasive answer with a wrong chart fact is a failure even when the user likes it.

9. Prove superiority against a strong alternative#

Do a small, randomized comparison before committing to the full chat roadmap. Recruit roughly 20 target users with actual questions; exclude founders and close friends from the principal preference count.

Compare three experiences:

• A: your current report and existing explanations;
• B: a capable general-purpose model given the same correctly computed chart facts, relevant question and a competent explanatory prompt;
• C: the proposed Astro Chanakya experience with its reviewed rules, contextual explanations and uncertainty handling.

Give B a fair chance. Comparing your product against a chatbot guessing the chart from birth details would exaggerate your advantage. Use participant-approved data, avoid account-identifying details, disclose processing, randomize display order, and have users evaluate answers without brand labels. Separately test the full interaction, because one-time text preference misses the benefit of convenience and follow-up.

Ask: Which explanation helps you understand the report? Which statements can you trace to a basis? What remains unclear? Which would you use next time? After the exercise, show the real product and price and allow an actual purchase; willingness-to-pay questions alone are weak evidence.

A useful initial signal would be at least 12 of 20 choosing C as the answer they would use, alongside no critical quality failures. Record that choice as the primary measure before the test. Also ask users to rate clarity, relevance and how well they understand the answer's limits on the same five-point scales; use those ratings to explain the choice, rather than changing the winning metric afterward. This is a directional discovery gate, not statistical proof of superiority. Examine why the others preferred A or B. If C wins only on prettier formatting, improve packaging cheaply; do not assume you need a complex AI system.

If the current report performs just as well, improve its explanation and navigation first. If a general model is equally useful, identify what users still pay for—convenience, trustworthy settings, local timing workflows, language or support. If no distinctive value survives that comparison, reduce scope or change the initial use case.

10. Packaging: monetize a result before promising unlimited access#

Keep the existing free tools useful. Introduce one clearly differentiated offer rather than a confusing menu of subscriptions, credits, consultations and reports.

Suggested starting price hypotheses, not valuations or established market benchmarks: ₹199 versus ₹299 for the initial bundle in India; $4.99 versus $7.99 for a US pilot. These are test prices for the same clearly described offer, not currency conversions. Show the final charge and applicable taxes before checkout. Check actual payment/store charges for each existing distribution channel before choosing the final price.

With little traffic, begin with one price and interview buyers and non-buyers. Test the second after you understand objections. A sequential test is susceptible to cohort and seasonality differences; do not present a handful of purchases as a statistically valid price optimization. With enough traffic, randomly assign otherwise identical offers and compare contribution per eligible visitor, not just conversion.

Keep billing simple: no charge for a failed response, visible remaining allowance, clear expiry and accessible refunds/cancellation. A clarification needed because your system did not understand the question should not consume another paid answer. Do not charge per minute for text simply because a human consultation business does.

Avoid an unlimited plan until observed heavy-user costs are affordable. Avoid an annual-only offer that hides weak monthly value. A subscription should offer something renewed—useful weekly updates, evolving planning tasks, or meaningful continuity—not just access to a static natal report.

11. The economics you must instrument#

Track cost per successfully delivered, accepted-quality answer, including failed attempts, retrieval, checking, retries and fallback calls. A cheap model with many rejected answers can cost more than a better model. Also measure p50/p95 cost per paying user; averages can hide a small group consuming the entire margin.

The following is an illustrative sensitivity model in rupees. It is not your observed performance, a model-provider quote, or a forecast. “Net sales” means sales excluding indirect taxes but before refunds and the variable costs shown. The assumed 5% collection/platform cost is deliberately a scenario input; replace it with actual web, Android and iOS costs separately.

The same offer can look attractive or lose money depending on cost and use. At 100 paid answers in the middle case, delivery alone is ₹300 against ₹200 net sales. Limits need to be designed into the offer, not added only after costs become a problem.

Free answers also cost money. In a deliberately simplified fully matured acquisition cohort, if every visitor who receives a free answer consumes exactly one answer at ₹1 and 5% become paying customers, the free-answer expense is ₹20 per payer. Five free answers each would make it ₹100 per payer. This includes the free trial usage of eventual payers and assumes every participant uses the full allowance. Measure actual consumption and conversion together instead of assuming that assumption holds.

That would reduce the efficient case's ₹142 contribution to ₹122 with one free answer, before content or other acquisition costs. Avoid double-counting that free-answer expense if it is already in your cost-of-service or acquisition ledger.

Use these definitions consistently:

Contribution = net sales - refunds - payment/platform charges
               - variable generation - variable hosting - variable support

Cash acquisition cost = attributable acquisition cash spending / new paying customers

Full acquisition cost = (cash spending + founder/contractor production time valued consistently
                        + allocated free-user service costs) / new paying customers

Observed 90-day contribution per acquired customer
  = cumulative contribution from a fully observed acquisition cohort / cohort customers

Cash runway = unrestricted cash / average monthly net cash burn

Keep fixed founder compensation, retained reviewer costs and fixed infrastructure in the operating budget. If a reviewer is paid per answer, put that charge in variable delivery instead. Do not call contribution company profit. Do not estimate lifetime value as monthly revenue divided by early churn when you have not yet observed stable cohorts.

A scale illustration: 1,000 customers paying ₹299 in a month would produce ₹2.99 lakh in gross billings; 3,000 would produce ₹8.97 lakh, before taxes, refunds and costs. This is arithmetic, not a revenue target or demand forecast. At the efficient-case ₹122 contribution after free-answer allocation, an assumed ₹1.5 lakh monthly fixed cost would require approximately 1,230 paying customers to cover it, before other acquisition costs. Replace every input before using this for a spending decision.

A useful initial operating ambition is positive observed contribution on the paid pilot, improving toward at least 60% before fixed costs and acquisition, while measuring all free-user costs separately. The 60% is a proposed business target, not an astrology industry benchmark. If good answers cannot meet the economics, increase price, reduce included volume, offer a bounded report, or narrow scope; do not silently degrade quality.

12. The dated 90-day roadmap#

Use the 2 November content start as the execution anchor. Neither public availability nor an AI launch is promised on that date. Each phase proceeds when the previous evidence is adequate. Lack of traffic may delay the learning schedule; publishing more features does not solve that by itself.

Roles below are assignments to agree between you, not assumptions about who has which skill. Product owner owns customer research, content, packaging and support. Engineering owner owns calculations, AI, instrumentation and release reliability. Both review decisions. A domain reviewer checks traditional-method fidelity and uncertainty handling.

Do not force a feature onto every platform simultaneously for the experiment. Choose the existing surface where users are easiest to recruit and updates easiest to ship; reuse the same backend and calculation contract. Once the journey works, integrate it coherently across the apps you already have.

Calendar reality matters: a subscription first sold on 14 December can have a first monthly renewal around 14 January. Its next renewal is around 14 February, outside this 90-day window. Do not claim that the January review demonstrates several months of subscription retention. Continue observation before increasing commitments.

13. The decision gates and dashboard#

Use few metrics with exact definitions. Never let a rise in messages hide that users are confused or repeatedly seeking reassurance.

For early one-off sales, prioritize useful paid topic completions, refunds and contribution per qualified activation. Track explicit usefulness feedback with its coverage; a completed screen alone does not prove usefulness. If the subscription hypothesis survives, add weekly returning activated users and actual renewal cohorts as the principal recurring-value measures.

Suggested decision rules are starting hypotheses and must be recorded before seeing results:

• Broaden paid availability: the release suite passes; at least 10 independent target customers have actually paid for a delivered experience; observed paid-unit contribution is positive; serious complaints are resolved. Ten purchases show initial willingness to pay, not product–market fit.
• Test a subscription: at least two fully observed activation cohorts of approximately 50 users each; at least 20% in each return meaningfully in days 22–28; interviews show a recurring reason; at least ten returning users are willing to buy the explicit monthly offer. Treat small numbers as directional and run a limited pilot.
• Increase recurring spending: observe at least two monthly renewal opportunities and more than one acquisition cohort, stable quality and positive contribution after free-user/acquisition costs. Compare absolute retained counts, percentages and uncertainty. The 90-day plan may not reach this gate.
• Rework the offer: users find answers useful but do not buy; inspect relevance, packaging, trust and price. Avoid assuming that a larger free allowance solves the issue.
• Reconsider the AI investment: after two substantive iterations, it still does not outperform the alternatives for the chosen use case, or realistic price/usage cannot produce positive contribution. Keep the useful existing tools and change the hypothesis.

If a cohort is too small or not mature, the decision is insufficient evidence, not success or failure. Do not slice 100 users into numerous age × language × country subgroups and assign significance to noisy differences. India and diaspora can be compared directionally first; choose one lead market for a credible follow-on cohort if resources are limited.

Minimum event plan: journey_started, chart_computed, result_viewed, basis_opened, answer_requested, answer_delivered, answer_failed, feedback_submitted, offer_viewed, purchase_completed, credit_reversed, meaningful_return, subscription_renewed and account_deleted. Attach pseudonymous IDs, platform, source, intent, language, versions and coarse error category. Keep raw birth details, conversation content and sensitive topic descriptions out of general marketing analytics. Test events against real UI behavior; do not count a server request as a viewed answer.

14. Turn the content calendar into product learning#

The completed calendar runs 2 November–1 December 2026. Its content should lead into the current tools and accurately labelled beta access; it should not imply that the AI or paid bundle is already available.

The previous social audit examined 96 public posts, using bounded convenience samples. In the Astrotalk YouTube subset, 15 sign-specific transit Shorts had median views of 66,000 versus 4,150 for ten ritual/remedy Shorts. In the CHANI subset, six weekly forecast videos had median views of 47,500 versus 4,150 for six introductory explainers. These comparisons support testing specific and recurring content; they do not prove causation, viewer retention, customer acquisition or paid conversion. Full audit and limitations

Use four content-to-product paths:

Use separate source tags and a post ID. Ask one optional “What were you hoping to understand?” question in product. Classify themes manually each week without exposing private questions in analytics or social posts.

Keep Instagram and YouTube as the main distribution effort. Continue the previously planned total cadence of four short videos and one carousel weekly, plus a longer explainer every two weeks, only while it fits the team's capacity. If content crowds out customer interviews and product fixes, reduce volume. One useful series that attracts paying, returning users is more valuable than maintaining every possible channel.

Add only a few strong search pages around the tested workflow. Include a working tool, a clear explanation, methodological limits and an appropriate next action. Do not launch hundreds of AI-written pages before confirming quality and demand.

After useful answers, let users preview and voluntarily share a summary without birth details or intimate questions. Measure recipient activation and paid contribution, not share taps alone. Test a creator collaboration against the same customer-quality measures. Organic acquisition still consumes labour, support and free-service costs.

15. The six-to-twelve-month roadmap is conditional#

These are options, not a promise to build all three. If reports sell and subscriptions do not retain, invest in better report discovery, fulfilment and event-driven repeat purchases. If weekly use is strong but payment is weak, fix packaging before multiplying content. If one language produces better customer economics, deepen it before expanding geographically.

A professional tool for astrologers could eventually reuse the engine and explanation system, but it is a different buyer with different workflow requirements. Do not simultaneously launch consumer chat, a marketplace, a professional SaaS tool and a commerce store.

Defer voice, avatars, dozens of AI personas, additional divination systems, gemstone/ritual commerce, open communities, a full human marketplace and model fine-tuning until a specific observed bottleneck justifies them. Voice is worth testing when language or accessibility research shows text is blocking value—not merely because it makes an impressive demo.

16. Build the company with the same discipline as the product#

Assign one decision owner per area. A two-person company cannot afford continuous ambiguity about whether product, content or technical quality has priority.

Under the 50-hour combined weekly assumption, begin with roughly 20 hours for engineering/quality, 10 for research/support, 10 for content/distribution, five for domain review coordination and five for metrics/operations. Treat this as a starting allocation, not a fixed productivity standard. Use a work-in-progress limit of one main product experiment and one main distribution experiment.

Suggested cadence:

• Monday, 45 minutes: inspect the previous week's customer and quality evidence; choose the single largest bottleneck; agree what will be learned by Friday.
• During the week: observe customers, implement a small change, review failures, and ship behind a flag when appropriate. Keep support close to the founders.
• Friday, 60 minutes: demonstrate the actual experience, review cost and cohort changes, decide whether to keep/rework/stop, and update the decision log.
• Monthly: inspect cash, mature cohorts and recurring commitments. Review whether you are still serving the same customer situation.

Each experiment gets a one-page record: hypothesis, target user, change, primary measure, quality/cost guardrails, sample/time window, owner, result and next decision. Preserve unsuccessful experiments; otherwise it is easy to repeat them with a different feature name.

Before material spending, agree founder responsibilities, time commitments, decision rights, ownership of existing and future IP, access to domains/app-store/payment accounts, compensation expectations and what happens if one founder leaves. Put the commercial/legal arrangements into appropriate written agreements with professional help. This is especially relevant because one founder wants to add AI and the company needs a shared definition of success.

Set a 90-day experiment budget you can afford to lose. Divide it explicitly among domain review, generation/hosting, user research incentives, necessary legal/licensing work and a reserve. Actual costs are unknown, so this report does not invent a budget quote. Put daily generation caps, alerts and a monthly service-spend ceiling in place before acquisition expands. Interview compensation should pay for time, not require a favourable review or purchase.

Hire or contract against the bottleneck. Initially, a qualified reviewer and occasional specialist help may provide more value than additional engineers. Hire a full-time role only when the work is recurring, clearly owned, supported by runway and tied to a proven need. Raise capital if it accelerates a demonstrated opportunity; funding does not resolve uncertain demand or poor retention.

17. Trust and privacy are product requirements for this use case#

AI astrology invites questions about relationships, money, work and distress. Design the response behavior, rather than relying on a footer disclaimer to compensate for an alarming answer.

For the initial AI pilot, use adult accounts and avoid collecting children's charts or questions. Partner charts require an appropriate permission flow; a partner invitation is preferable to encouraging secret uploads. Make clear what any recipient will see before a comparison or family plan is shared.

Create a data inventory covering birth inputs, chart tokens, derived chart facts, account identifiers, questions, saved context, reports, billing and logs. For each, specify purpose, storage location, access, retention and deletion. Derived chart data may still identify or reveal information about someone; removing their name does not automatically anonymize it.

Before turning on AI, check provider retention/training terms, access permissions, deletion behavior, cross-border processing and the handling of backups and monitoring logs. Minimize the information sent to the model: a selected computed fact set usually does not require a full name or raw birth address. Make conversation history optional where feasible, and separate service processing from any consent to use examples for quality research or training.

India notified the DPDP Rules in November 2025 with phased implementation. Map the actual launch dates, product behavior and selected diaspora jurisdiction to applicable obligations rather than assuming all provisions have the same start date. The government's 2025–26 annual report describes the notification and eighteen-month phased timeline. MeitY annual report, data protection section Have the specific notice, consent, retention and payment requirements checked for the markets you launch in; this report does not establish legal compliance.

Your existing privacy notice is a useful starting inventory, but adding AI providers, retained chats or new mobile analytics changes the data flow. Test that consent withdrawal and deletion actually work across the application, model-service storage if any, caches, reports and support tooling. Publish retention exceptions plainly rather than promising instantaneous universal deletion you cannot perform.

18. Definition of done for the first paid AI release#

The feature is ready when a target user can complete the supported task, the team can explain the answer's basis, and the company can afford and support the delivery.

• One customer situation, a clear offer and one owner are written down.
• The existing calculation dependency, method, licence and default settings are documented.
• Exact/approximate/unknown birth-time modes behave as described.
• Answers use versioned computed facts and reviewed rules; unsupported scope has a useful fallback.
• The current release suite passes, with language-specific results and critical failures addressed.
• Pricing, allowance, expiry, failed-response handling, refunds and cancellation match the actual checkout and billing logic.
• Account separation, AI provider data flows, retention, deletion and consent have been checked.
• Funnel, costs and quality events work without exposing private questions to marketing analytics.
• Founders can inspect a reported failure, correct it, reverse a charge when appropriate and roll back a release.
• The pilot has real customers and observed costs, not only a compelling demo.

19. Your next seven working days#

These are working-day priorities, not a requirement to finish a validated production AI service in a week. The 90-day gates govern expansion.

20. Companion materials and source use#

The execution backlog translates the roadmap into proposed owner roles, dependencies and acceptance criteria. Every row is planned work, not a claim of implementation.

Related existing work:

• Positioning and organic growth strategy
• 96-post social research report
• 2 November–1 December calendar and ready-to-use copy
• Editable content calendar workbook

Public competitor capabilities and prices are snapshots of pages reviewed on 25 October 2026. They were not checkout-tested. Company usage claims are labelled as such. Subscription research is observational and drawn from the provider's customer population. All proposed prices, sample sizes, dates, cost scenarios and release/business thresholds are planning assumptions to validate against your actual product and customers.