Budget: 75 PLN Deadline: 1 day
contact us
Subject: Optimization of scraping OLX.pl + Otodom.pl for a paid Telegram bot (minimum traffic/proxy + analysis of "how free bots operate")
I am looking for a freelancer who can help optimize scraping OLX.pl and Otodom.pl for a Telegram bot that monitors real estate listings in Poland.
A paid service for monitoring real estate listings based on user criteria.
Price: 1 zł/day (~30 zł/month) for 1 active monitoring (set of filters).
Sources: OLX.pl + Otodom.pl (the main Polish real estate platforms).
Sending logic:
every 15 minutes — check (cycle)
per cycle, we look for up to 5 new listings
we send not everything at once, but every 3–5 minutes 1 listing, to spread the load (about 4 cycles per hour)
There is a VPS + Docker, there is a scraper/bot.
Database: Supabase, part of the logic in Supabase Functions.
Telegram bots already exist: separately for settings, separately for notifications, separately for support.
We do not upload photos (do not download images), we only take:
text/description
links
filters
links to all images (URL), without downloading the file
If several users have identical filters, we perform 1 unique search for all, without duplicating requests.
Even after optimizations regarding photos and “merging identical searches,” proxy costs are high because:
the listing page (search result) can weigh ~400–500 KB per request
the detailed listing page (to get the full description/parameters, if they are not in the listing) can also weigh ~500 KB
if we take up to 5 listings per cycle — total traffic can be ~3 MB / 15 min
this results in approximately ~288 MB/day, ~8.6 GB/month for 1 unique search
at a conditional proxy price of 1 GB = 10 zł, it turns out that one active search can cost more than the client's subscription (30 zł/month), especially if there are many searches (16 cities and more)
There is a point I want to clarify:
I am subscribed to several free Telegram bots/channels that have been operating for months on OLX/real estate.
They send hundreds of messages daily with new listings.
They do not have:
subscriptions/paid features
advertising
obvious monetization
At the same time, their infrastructure/proxy costs must clearly exist — but they somehow manage it and do not shut down.
Therefore, it is necessary to understand how to obtain “unlimited traffic” without bans or another way to obtain data
Budget: 75 PLN Deadline: 1 day
contact us
Budget: 75 PLN Deadline: 1 day
Good day. It seems to me that you are simply fighting in the wrong direction. I have been working with OLX for several years, I can consult for free.
Looking forward to working with you!Budget: 200 PLN Deadline: 1 day
Hello!
I develop bots for Telegram using NodeJS. I am ready to take on the task. Write to me, we will discuss.
Budget: 500 PLN Deadline: 2 days
Hello,
I had experience working with a popular agency in Warsaw called Grand, if you know it. But there we were collecting data in conjunction with other platforms (MLS and others, I don't quite remember the names), there is also a service from which additional information can be collected, possibly even without a proxy. Write to me in private messages, I am ready to help with what I can and provide consultation.
I would be happy to collaborate!
Budget: 75 PLN Deadline: 1 day
Hello!
I have extensive experience in writing parsers/Telegram bots.
I have been working with Python and VPS for 5 years.
I will help you solve your issue very quickly and efficiently.
Feel free to reach out!
Budget: 1700 PLN Deadline: 15 days
Optimization of scraping OLX.pl and Otodom.pl for a Telegram bot requires a comprehensive approach to reducing costs on proxies and ensuring stable access to data. In your case, a key factor is reducing the number of requests to listing pages and detailed ads, as well as using effective data retrieval methods. In particular, one can focus on analyzing free bots to identify how they avoided bans or minimized traffic. For example, the use of headless browsers with smart session management, integration with platform APIs (if available), or optimization of search logic to minimize duplicate requests is possible.
My experience in developing microservices, optimizing infrastructure, and working with Telegram bots allows me to propose solutions that will reduce the load on proxies. For instance, a proxy management system with automatic selection of optimal routes can be implemented, as well as using caching for repeated requests. Additionally, to reduce traffic, a more efficient page processing logic can be implemented — for example, parsing only the necessary data (text, links) without loading the full page.
A key stage will be analyzing free bots to identify technical patterns that allow data retrieval without high costs. This may include the use of private APIs, smart session management, or optimizing request frequency. It is also important to consider the possibility of integrating with other sources or using alternative data retrieval methods to avoid platform restrictions. The approach should be flexible, tailored to your schedule and budget, taking into account scalability in case of an increase in the number of users.
Budget: 500 PLN Deadline: 3 days
Hello! I have studied your project and am ready to start working. I am confident that I can meet all your expectations.
Budget: 3000 PLN Deadline: 3 days
🤝 Quality solution to your task — exactly on time
Hello! I have studied the description of your project and am ready to start implementation.
I guarantee deep immersion in the project and thorough work on all details.
I strictly adhere to deadlines. The work will be ready on time or earlier.
Always in touch and provide reporting at key stages.
I look forward to your feedback!
Budget: 300 PLN Deadline: 3 days
Hello. I have experience with parsers for OLX and similar sites. I can optimize the loading of the page itself, that is, load only the necessary fields, or if possible, through the internal APIs of the sites.
Budget: 5000 PLN Deadline: 5 days
Hello! I have significant experience in optimizing parsers for large-scale projects. I have worked with OLX and Otodom, and I understand the specifics of their protection and limits.
📌 What I offer:
• Analysis of the current code and identification of "bottlenecks" in traffic consumption.
• Implementation of effective strategies for using proxies and rotating User-Agents.
• Optimization of requests to minimize the transfer of unnecessary data.
• Configuration of asynchronous parsing to increase speed.
• Integration with a Telegram bot with minimal delay.
I guarantee quality optimization that will reduce your infrastructure and proxy costs.
Budget: 350 PLN Deadline: 5 days
worked with parsing from Odom and OLX.
write to me, I will tell everything.
you initially have an incorrect architecture
Budget: 6000 PLN Deadline: 5 days
Hi,
I can help you analyze, redesign, and significantly reduce the traffic and proxy costs of scraping OLX.pl and Otodom.pl for your Telegram monitoring service, while keeping it stable and ban-resistant. I have hands-on experience with high-frequency scraping, traffic optimization, and anti-bot evasion, especially for marketplaces and classifieds. Your current architecture, with VPS + Docker, Supabase, merged searches, and no image downloads, is solid, so the main challenge is data acquisition strategy and cost efficiency.
I would start by reverse-analyzing how free OLX/real-estate bots operate long-term without visible monetization. In practice, this usually involves avoiding full page loads, using lightweight endpoints or internal APIs, aggressive caching, diff-based checks instead of reloading entire search pages, conditional fetching of detail pages only when necessary, request fingerprinting that mimics real users, and smart scheduling instead of fixed intervals.
Next, I’d focus on cutting traffic per cycle, not just reducing proxy usage. This includes reducing payload size per request, eliminating unnecessary HTML/JS content, detecting new listings without loading full result pages, and minimizing detail-page fetches by extracting more data directly from listings.
Finally, I can help evaluate alternative data access paths, such as hidden or internal endpoints used by OLX/Otodom frontends, low-cost or hybrid proxy strategies, and caching combined with selective fetching.
The outcome would be a clear explanation of how free bots operate for months, a concrete plan to reduce monthly traffic significantly, practical recommendations for keeping the bot stable at scale across multiple cities, and actionable changes for your existing Docker/Supabase setup. I don’t promise “magic unlimited traffic,” but I can help you get very close without bans while making the subscription model economically viable.
Happy to discuss details and start with an audit of your current scraper logic.
Best regards,
Tobias
Budget: 1000 PLN Deadline: 3 days
Good day!
I professionally develop Telegram bots and scrapers in Python. I have experience with APIs, proxies, Docker/Supabase. I am ready to analyze the work of "free" bots and optimize scraping of OLX/Otodom to minimize traffic.
Write to me in private messages, and we will clarify the details.
A parser needs to be created to collect competitor prices, with a catalog of over 40,000 products. Access to the prices is only available under authorization.
Good day, I need help with creating the logic and implementing an idea. A chat-bot for tracking the status of document production for an educational center.
Hello. Below is a conditional technical specification for the bot for our synagogue. We need not just a Telegram bot, but a convenient mini-application for the synagogue and community, through which a person can navigate the life of the synagogue, quickly get the necessary information, view the schedule, learn about events, register, and interact with us. In terms of style and logic, we can base it on the reference bot we showed, but we need a better version: more convenient, modern, useful, and with a clearer structure. If you have strong opinions on design, UX, and structure, and you see how to improve it, we are open to suggestions. The main idea: for a person to quickly navigate the life of the synagogue through the bot. What should be in the bot. 1. Main screen with specific buttons The main screen should have clear large buttons: Today Schedule Events Shabbat Jewish calendar My dates A-Yom Yom for today Synagogue services Contacts Donate Settings 2. "Today" section This is one of the main sections. A person enters and immediately sees what is happening today. What should be displayed: what is today's Jewish date what prayers are today what time they take place what events we have in the synagogue today important dates and events in the Jewish world if relevant — time for lighting candles and the end of Shabbat Buttons inside: Prayers today Events today Jewish date Shabbat / candles More details 3. "Schedule" section Through it, a person should conveniently view the schedule. Buttons: For today For tomorrow For the week For Shabbat For holidays What inside: Shacharit Mincha Maariv lessons meals holiday services other activities with time and, if necessary, location It is important that the administration can easily update this schedule. 4. "Events" section A full section on events is needed. What should be included: upcoming events all events card for each event registration In the event card: title date time location short description register button more details button Examples of events: Shabbat lesson youth meeting lecture charity lunch women's / men's meeting holiday outing 5. "Shabbat" section This should be a separate section, not just part of the schedule. What inside: time for lighting candles time for prayers time for meals time for the end of Shabbat weekly Torah portion brief information about the upcoming Shabbat registration for Shabbat Buttons: Upcoming Shabbat Shabbat schedule Weekly portion Register for Shabbat What you need to know 6. "Jewish calendar" section What should be included: today's Jewish date upcoming holidays Rosh Chodesh fasts memorial dates brief explanation of the day / holiday Buttons: Today Upcoming dates Holidays Rosh Chodesh Memorial dates 7. "My dates" section We take this idea from the reference, but want to make it useful. The user should be able to save: birthday Jewish birthday yahrzeit other important dates What the bot should do: store these dates remind about them allow setting notifications Buttons: Add date My dates Reminders Delete date 8. "A-Yom Yom for today" section What should be included: text for today convenient beautiful display ability to view the previous / next day share button Buttons: Today Yesterday Tomorrow Share 9. "Synagogue services" section This needs practical navigation. What can be included: registration for a lesson registration for Shabbat registration for an event ask a question volunteering charity programs other services / directions of the synagogue 10. "Contacts" section Should include: address phone Telegram Instagram YouTube email ways to contact us if necessary, geolocation Buttons: Call Write Open address Instagram Telegram YouTube 11. "Donate" section It needs to be done neatly and clearly. What should be included: donate button payment methods details / link brief explanation of what the funds are for contact for donation questions 12. "Settings" section The user should be able to configure: language daily notifications notification time Shabbat reminders holiday reminders reminders for personal dates Buttons: Language Notifications Shabbat Holidays My dates Enable / disable mailing 13. Daily mailing We need the bot to send people relevant information every day: what prayers are today what time they take place what events we have in the synagogue today what important dates and events are in the Jewish world today if relevant — time for candles / end of Shabbat That is, a person opens the bot in the morning or receives a message and immediately understands the picture of the day. 14. Registrations and sign-ups Through the bot, there should be an option to register for: Shabbat lessons events meetings other activities Logic: a person presses a button leaves their name phone / username if necessary, additional data the application goes to the administrator / to a table / to CRM 15. Admin section It is important for us that the bot is easy to manage. The admin should be able to: update the prayer schedule add and edit events change texts launch mailings see registrations and applications change contacts and links It is important that this is really convenient for maintenance, not too complicated. 16. Support and development At the first stage, it is not necessary to do everything at once; a strong first version can be launched, and then supplemented in the process. But it is important to immediately foresee: the possibility of expansion support and maintenance of the bot after launch bug fixes improvements during use 17. What is important in the end We need a bot that will become a mini-application for our synagogue and help a person navigate conveniently: what is today what prayers what events what will happen on Shabbat how to register how to contact where to view the Jewish schedule what is happening in our synagogue and in the Jewish world If you see how to make the structure, buttons, design, and logic better than in the reference bot, that is a plus. We need not a clone, but a stronger, more convenient, and modern version. https://www.hebcal.com/home/developer-apis Chabad.org
Development of a Telegram bot: a closed platform-marketplace for experts I am looking for a developer (or a small team) to create a Telegram bot — a closed platform that connects verified experts and clients for solving professional tasks. The model is similar to a service marketplace with a supervising administrator, rather than a fully automated service. What is ready: A detailed technical specification (30+ pages) — user roles, step-by-step UX flows with button texts, status models for Requests/Cases, data model, payment status model, admin panel. Key functionality: - Two user roles (client / expert) with the possibility of combination - Verification of experts through the administrator (without automatic decision approval) - Selection and moderation of requests by the curator - Internal communication space within the bot (without disclosing contacts between parties) - Payment status model: escrow, confirmation of funds receipt, payments - Referral system with bonuses - Administrative panel with extended access rights Expected stack: at the discretion of the developer (Python/Node.js), the main thing is — experience with Telegram Bot API, working with states (FSM), databases, and payment integrations. Collaboration format: work based on the ready technical specification, discussion of deadlines and budget after reviewing the document. What to send: examples of implemented Telegram bots (preferably — with complex state logic or payments), an estimated timeline and cost.
Technical assignment for the client search automation system in Telegram Development 1. General task It is required to create an MVP system for automatic client search in Telegram chats with the provision of found users to sales department operators. The system should consist of: user bots based on Telethon; Telegram bot for operators; Telegram bot (or a separate administrative section within the bot) for the administrator; PostgreSQL database; Docker configuration for deployment in configuration. A web panel is not required at this stage. 2. Working with multiple Telegram accounts The system must not be limited to one Telegram account. It is necessary to ensure support for multiple accounts (for example, 5 or more) with the ability to increase their number without changing the configuration. For each account, there should be the ability to: authorize via Telethon; maintain its own session; connect a new account; disconnect an account; replace an account without losing the database. The administrator should be able to independently connect new Telegram accounts. 3. Distribution of chats among accounts The system will use a large number of Telegram chats (approximately 800 or more). All chats are included in a single system. The system should automatically: manage chats among connected accounts; observe Telegram restrictions; Handle the need to transfer a chat to another account; Prevent duplication of one chat by multiple accounts (unless specifically included). It is desirable to ensure load balancing among accounts. 4. Managing the chat list The administrator should be able to do this without the developer's involvement: connect a chat; delete a chat; import a list of chats from a file; bulk upload chat costs; enable or disable monitoring of individual chats; restart history collection for a selected chat. After adding a new chat, the system automatically includes it in one of the key accounts. 5. Data collection For each connected account, it is necessary to implement: Initial parsing After adding a chat: loading message history for the specified period; saving all available information. Monitoring After the initial loading is completed: constant tracking of new messages; saving new users; saving new activity of existing users. 6. Handling Telegram blocking requires proper handling: FloodWait; PeerFlood; temporary Telegram restrictions; erroneous connections; connection breaks; possible reconnections; temporary unavailability of the account. If one account is temporarily blocked by a restriction, the rest of the work continues. 7. User data storage. For each user, the following should be saved: Telegram ID; first name; last name (if available); username; profile link; list of all chats; message text; date and time of the message; link to the message (if obtainable from Telegram). User merging is performed exclusively by Telegram ID. If a user has written in 20 chats — they display one card. 8. User card The operator should see: first name; username; Telegram ID; profile link; list of all chats; messages; activity date. Example: User: Ivan Ivanov ID user : 123456789 Chat "Business": Message: "Good day, interested in advertising" Date: 01.03.2026 12:15 Chat "Marketing": Message: "Who is handling promotion?" Date: 05.03.2026 18:42 9. Operator work The system should automatically form a queue of clients. After receiving a client: the user is assigned to an operator; the second operator cannot receive the same client; maintain a history of actions. Statuses: Took the client; Unavailable; Could not reach; Refusal; In progress; Call back; Delete. After selecting a parameter, the next client will automatically open. 10. Reissuing users There should be an option to configure user reissuance. For example: never; after 30 days; after 60 days; after 90 days; arbitrary period. 11. Administrative section The administrator should be able to: Account management add an account; delete an account; view account status; view account restrictions; replace an account. Chat management add; delete; import; export; disable monitoring; disable monitoring. Operator management add; delete; block; change rights. Parser management start collection; stop collection; rebuild history; view current status. Statistics View: number of users; number of messages; number of processed clients; number of active operators; number of connected accounts; number of active chats. 12. Database Use PostgreSQL. It is necessary to store: users; messages; chats; activity; Telegram accounts; operators; processing statuses; processing history; distribution of chats among accounts. 13. Scalability The architecture should provide the ability to: connect 10, 20 or more Telegram accounts; connect thousands of Telegram chats; handle load; export data; work with CRM; connect new features without a complete project overhaul. 14. Docker The executor should set up: docker-compose.yml; Dockerfile; launch instructions; update instructions; database backup instructions. The system should manage the command as one.