Astrogenerator - Horoscope Generation Telegram Bot

Overview

A practising astrologer and numerology specialist came to us wanting a tripwire - the cheapest product in her offer, the one that introduces someone to her approach and leads them toward the main product, a one-to-one coaching session. The format we settled on: a Telegram bot that sends an engaging horoscope every day - the general one for everybody, and, on a 390 ₽/month subscription, a personal one calculated from date, place and time of birth.

Technically the bot runs on the Browser Automation Studio engine: the text comes from ChatGPT via the API, and the lunar-day card is drawn by the bot itself from live astronomical data. The bot was later ported to Python - more on that below.

Problem

The astrologer had the problem every specialist selling their own time has: working out a horoscope for one specific person takes hours, and there is no way to multiply yourself by the number of people who want one. As a result the offer was missing its bottom rung - a cheap product someone starts with. Every new lead had to be warmed up by hand, or not at all.

The brief was its own difficulty. There was no specification - the client arrived with “build something like this bot”, with no detail on screens, plans or generation rules. So the first part of the job was to design the product on the client’s behalf and show it as a working bot rather than a document.

Solution

The bot collects data once, on first contact: name, gender, date, place and time of birth - validated at every step, down to checking that the name was typed in Russian. A natal chart is built from that, and the subscriber never fills anything in again: the record lives in the database along with the zodiac sign, the plan, the subscription window, the send time and the last text delivered.

Text is generated through the OpenAI API, with the branch depending on the plan: a free subscriber gets the general horoscope of the day, a paying one also gets the personal reading, split into day, love and health sections.

The visual side is what makes the broadcast recognisable. Every day the bot draws a “Moon today” card: day and month, lunar day, phase, sign with exact degrees, moonrise and moonset. The moon and phase data come from a third-party astrology service and are composited onto a backdrop by the BAS image processing module.

Features

• First-contact questionnaire with per-field validation and a natal chart built from date, place and time of birth
• Daily horoscope and personal horoscope generation through the OpenAI API, with day, love and health sections
• Two content branches by plan: free, and a paid 390 ₽/month subscription with start and end dates
• Daily “Moon today” card generation from live data: lunar day, phase, sign with degrees, moonrise and moonset
• Astronomical data pulled from a third-party astrology service
• Subscriber database in BAS: profile, zodiac sign, plan, send time, last horoscope text and post image
• Asynchronous message receiving and sending, per-command scenarios, and a button through to the personal horoscope
• A separate support account for correcting data entered wrongly
• Response-length control to stay inside Telegram’s 4,096-character limit

Development Process

The work split into four non-trivial parts, and the difficulty was distributed nothing like we expected.

Architecture. This meant designing the database, asynchronous message receiving and sending, and the scenario logic behind each command. Every profile field is filled on first contact, which makes validation more than cosmetic: an error in the date or time of birth means a wrong natal chart and a wrong horoscope for the whole subscription.

Wiring up the model. We started on davinci-003 and then moved to gpt-3.5-turbo, the current version at the time. The move was forced and useful at once - text quality rose noticeably.

The prompt was the longest part. It took roughly two weeks out of six, because the acceptance criterion was the astrologer’s taste rather than a specification. We worked through temperature and max_tokens settings, hunting for phrasing that kept the output both meaningful and recognisably in her voice. In parallel it had to fit Telegram’s 4,096-character limit - asking the model for substance and brevity at the same time.

The lunar-day card. Here we hit a detail that captures this kind of work nicely: when the day of the month is a single digit, it gets padded with a leading zero, otherwise the text drifts out of alignment with the backdrop. Things like that are not designed - they are found, on the first of the month.

A note on the tooling. The project could have been written in Python from the start, and that is where it eventually moved. BAS was a deliberate experiment: could the engine carry a full product of this class? It could - six weeks produced a working bot with a database, text generation, image generation and plans. But for the long haul of maintenance Python made more sense, so the bot was ported.

Delivery did not end with handing over the bot. I reworked the content-production process, prepared the research, instructions and templates, and trained the astrologer’s assistant to run it - rolling out the new process was on us.

Results

• The bot shipped in six weeks, database, plans, text generation and image generation included
• The daily grind of writing horoscopes came off the astrologer entirely - both the general and the personal readings are produced without her
• The offer gained its missing bottom rung: a 390 ₽/month subscription that introduces the approach and leads to one-to-one work
• Per the client, sales grew fourfold
• The assistant runs the bot from instructions and templates, with no developer involved
• The premise that BAS can carry a product, not just an automation script, held up on a real project

What Was Learned

The main observation from this project is that the real work was not in the code. Architecture, the database and the API integration all took less time than the prompt: two of the six weeks went into text that would satisfy someone who sells her expertise through it. When the acceptance criterion is the client’s taste, the only strategy that works is a fast show-listen-rework loop, and the product gets designed in the conversation rather than in a document.

The second is about the missing specification. A client who says “make it like that one” is not sabotaging the project - they simply cannot describe something they have not seen yet. A working prototype beats ten pages of sign-off in that situation, which is exactly why picking a fast engine for the first version was the right call. The same logic - a working version first, the right platform second - repeated later in other projects, including the Telegram course sales bot.