Source
The pages we take fields from: price, name, stock, link.
Data from other sites on a schedule: prices, stock, competitor cards. The result arrives as a sheet or in your system.
The set depends on the site and on where the result should go. The first source is its own piece of work.
The pages we take fields from: price, name, stock, link.
Anti-bot bypass and proxies where the site requires them.
A run on its own, with a record of when it passed and how many rows it brought.
A sheet, a file, or a write into your base, CRM or API.
If a layout change breaks the run, it shows in the log instead of failing quietly.
A system for a client who analyses vehicle damage from US salvage auctions. The goal was to collect photos of thousands of lots and organise them into an archive that is easy to work with. What was built: • A Telegram bot: the client sends an auction export (Excel, CSV or zip), the bot selects the matching cars and downloads every photo of each lot. • Filtering by year, makes and damage types, adjustable with buttons right in the bot — no developer needed. • Tidy storage: Damage / Make / Year / Model / Lot_VIN, with a data file per lot — VIN, trim, damage, mileage, title, sale date. Source tables are kept unchanged, with checksums. • Live progress, stop and resume, no duplicates, a disk space check before every download. • Robust to real-world Excel files: multiple sheets, CSV from localised Excel, duplicates, extra columns. • The archive mounts as a network drive on Windows and macOS over secure SFTP. • The server is provisioned and updated with a single command: Docker, firewall, brute-force protection, key-only login. Runs on a 1 GB VPS. • 195 automated tests; a deployment stops automatically if any test fails. Result: from a daily export of 50,000 lots the bot picks the relevant ones and builds the archive — 12–13 photos per car on average, with no manual work. Stack: Python 3.12, aiogram 3, openpyxl, Docker, Ubuntu, OpenSSH/SFTP, pytest.
A service for a client who needed to find out about free appointment dates at Lithuanian consulates in time: slots appear rarely and are gone quickly. What was built: • Regular checks of the online appointment schedule across three consulates at once. • Telegram notifications as soon as a free date appears, with the consulate and the date. • A history of found slots: what appeared and when, with no repeat alerts for the same slot. • Detailed logs and page screenshots on errors, so problems are visible immediately. • Migration from Selenium to Playwright with an asynchronous architecture: more stable, faster and lighter on resources. Result: the client learns about a free slot within seconds of it appearing and has time to book it, instead of refreshing the page by hand. Stack: Python, Playwright (previously Selenium), asyncio, TinyDB, Telegram Bot API.
The first source starts at the figure below. More sources, and delivery into your system, are priced separately.
Price, stock or catalog monitoring from one site.
From $300
The same fields from different sites in one sheet.
By quote
Delivery to a sheet, a CRM or an API, and a message if a run stops.
By quote
The first month of support is included. After that, by agreement — the same as for the other services.
Every stage ends with a result you can check.
Yes. One source covers one site. The others, and delivery into your system, are added separately.
The run writes the error to the log. If the protection changed, a fix is part of the support month, and after that by agreement.
Usually from three days: the fields, the run, a check on live pages, and the handover.
Tell us about your task — we will reply within a day with questions or a first estimate.