Source: https://daphnislabs.com/case-studies/astro-app

# Astro app

From finding an astrologer to a paid consultation

Native Android and iOS development in Kotlin and Swift for Nakshatra, a product connecting customers with astrologers.

[Read the story](https://daphnislabs.com/case-studies/astro-app#story)

![Astrologer profile — original interface design](https://daphnislabs.com/images/projects/astro-app/expert-profile.webp)

![Nakshatra sign-in — original interface design](https://daphnislabs.com/images/projects/astro-app/login.webp)

## The project

A consultation marketplace needs to coordinate more than messages: who is available, whether a customer can fund a session, when the expert accepts it and how the session ends. Nakshatra brings these decisions into a mobile experience with separate customer and astrologer roles, supported by an administration panel.

### About these images

Screens are selected from the supplied 25-page interface-design PDF, not captures of a running app. Names, balances, ratings, prices and dates are example content. Implementation details below come from the historical Android handover; they do not independently establish iOS feature parity. Kotlin and Swift are owner-confirmed; the older handover includes Java snippets. The live-session design is broader than the documented YouTube-based implementation.

**Industry**

Astrology & expert consultations

**Our role**

Native Android development Native iOS development

**Technology**

Kotlin Swift Firebase REST APIs Razorpay

**Product**

Nakshatra Customer & astrologer apps

## Inside the customer experience

Original interface designs, with implementation context from the project handover.

![Birth details and account registration — original design](https://daphnislabs.com/images/projects/astro-app/onboarding.webp)

### Establish the consultation profile

Phone, Google and Facebook authentication provide the account entry points. New customers complete a profile with date, time and place of birth; returning customers continue to the home screen. Customers can later edit their own details.

![Wallet balance and history entry points — original design](https://daphnislabs.com/images/projects/astro-app/wallet.webp)

### Keep funding and records together

The wallet groups the available balance, recharge entry and transaction histories in one place. Razorpay is named in the Android implementation; the PDF's payment-method labels are design references, not evidence of the final provider configuration.

![Consultation message timeline — original design](https://daphnislabs.com/images/projects/astro-app/conversation.webp)

### Give the conversation its own space

The chat view separates the message timeline from the composer and delivery status. The original designs also show a conversation list with message previews and unread counts, giving returning customers a route back to their exchanges.

![Previous consultations and order summaries — original design](https://daphnislabs.com/images/projects/astro-app/chat-history.webp)

### Make past sessions inspectable

Separate call and chat histories organise previous consultations. The chat-history design pairs the order reference and date with duration, per-minute rate and the amount deducted, plus controls to view the conversation or start another chat.

![End-of-chat rating prompt — original design](https://daphnislabs.com/images/projects/astro-app/feedback.webp)

### Ask for feedback after the session

Reviews are public on the astrologer's profile, but the rating prompt appears only after a chat ends. Customers can submit a rating or skip the prompt, keeping feedback tied to the consultation lifecycle.

![Live-viewing concept — documented implementation opens YouTube](https://daphnislabs.com/images/projects/astro-app/live-concept.webp)

### Connect live discovery to YouTube

The Android handover describes upcoming, recent and live schedules that open sessions on YouTube. The original PDF explores an in-app viewer with comments and gifting; those richer designs are not presented here as delivered streaming or payment functionality.

## What happens before a chat can begin

The Android handover documents a wallet check and an explicit request-and-accept sequence between the two apps.

1.  ### Check the balance
    
    The customer must hold at least six times the astrologer's per-minute chat rate. An insufficient balance opens a recharge prompt. This is the recorded start condition, not a claim of a six-minute minimum charge.
    
2.  ### Request the expert
    
    Firebase Realtime Database records the requested state and a notification reaches the astrologer. A rejected request returns the customer to the home screen with a message.
    
3.  ### Create the shared session
    
    On acceptance, the astrologer app creates a chatroom through the server API and in Firestore. The customer's listener observes the accepted state, joins the room and starts the timer and heartbeat.
    
4.  ### Close from either side
    
    Separate states identify whether the customer or astrologer ended the chat. The end-session flow stops the heartbeat and moves the customer toward feedback.
    

## When a mobile session is interrupted

Closing an app or losing connectivity can bypass its normal end-chat action. The implementation therefore gives the server a recurring signal that the session is still active.

1.  ### A recurring heartbeat
    
    The handover describes a roughly ten-second ping cycle. Its sample schedules the next request nine seconds after a successful response and passes a ten-second waiting value to the API.
    
2.  ### Server-side termination
    
    If those pings stop arriving, the documented server behaviour terminates the chat and deducts the session amount. A server rejection or client request error also enters the end-chat procedure.
    
3.  ### Distinct communication channels
    
    Realtime Database carries request and session-state changes, Firestore participates in the conversation record, and Cloud Messaging delivers device notifications. REST endpoints coordinate chatroom creation and heartbeat handling.
    

## The expert and administration side

Expert profiles bring languages, experience, skills and consultation rates together. Astrologers have Online, Offline and Busy states; an active chat changes their status to Busy. Their profiles are edited through the administration panel. The documented call action invokes a calling API with the two parties and a maximum-duration parameter, and saves call data in Firestore.

## The recorded delivery boundary

The 2020 Android report flags unresolved server-related chat disconnections and marks Panchang as disabled at that time. A later fix, current release status and measured business outcomes are not established by the supplied material. This case study describes the documented product and its engineering decisions at that stage.

[All case studies](https://daphnislabs.com/case-studies) [Next project**FeeonTime**](https://daphnislabs.com/case-studies/feeontime)

## What are you building?

Bring us your idea. We’ll shape the next step together.

[Talk about your project](https://daphnislabs.com/contact?intent=plan-build)