Abstract
A Selenium-driven browser bot that automates the full Freelancer.com bid workflow — login, project search, bid-condition evaluation, and proposal submission — using undetected_chromedriver and BeautifulSoup for a stateful multi-page site.
1. What This Is
The bot automates repetitive project discovery and bid submission on Freelancer. It signs in through an automated browser, searches for Python-related projects, inspects project and bid information, and submits a proposal when configured conditions are met.
The selection rules — bid count and average bid amount — are kept separate from the browser interaction layer so they can be tuned without rewriting the automation sequence. The overall goal was to learn resilient web automation across a multi-step, stateful site workflow.
2. How It Works
The pipeline runs as a single sequential browser session. Each stage depends on the previous one completing successfully against a live, stateful website.
| # | Stage | Input | Tool | Output |
|---|---|---|---|---|
| 01 | Browser start & login | Credentials | undetected_chromedriver, Selenium | Authenticated session |
| 02 | Project search | Category keyword (Python) | Selenium navigation | Result / detail pages |
| 03 | Parse project & bid data | Page HTML | BeautifulSoup | Bid count, average bid, project details |
| 04 | Evaluate conditions | Parsed metrics, config thresholds | Python rule logic | Go / no-go decision |
| 05 | Submit proposal | Configured bid text, amount | Selenium form interaction | Submitted bid |
3. Implementation Notes
3.1 Selection rules decoupled from browser actions
The bid-count and average-bid thresholds live in a separate configuration layer. Changing a threshold or adding a new criterion does not require touching the Selenium navigation code, which keeps the automation sequence stable while the business logic evolves.
3.2 BeautifulSoup for DOM extraction
Where the project detail page exposes structured data in the HTML, the bot pulls the full page source and parses it with BeautifulSoup rather than issuing repeated Selenium element lookups. This is faster and less brittle for read-only data extraction, while Selenium handles the interactive steps — clicks, form fills, navigation.
3.3 Configurable proposal text
The bid/proposal content is read from configuration rather than hard-coded into the browsing logic, so the same automation run can submit different proposal text without code changes.
3.4 Terminal feedback via Colorama
Colored console output reports each decision point — project found, condition met or not, bid submitted — so the run can be monitored without attaching a debugger.
4. Constraints
-
Fragile to site and driver updates
undetected_chromedriver and Freelancer's DOM both change without notice. A Chrome update or a layout tweak can break selectors with no compile-time signal.
-
No retry or checkpoint logic
If the session drops mid-flow — timeout, CAPTCHA, rate-limit — the run stops. There is no resume-from-stage or exponential-backoff retry.
-
Basic selection criteria
Only bid count and average bid amount are evaluated. No scoring on budget range, client rating, deadline, or project description quality.
-
Single session, no tests
One account, one browser instance, sequential execution. No automated test suite; verification is manual console inspection.
5. Next
- a. Add retry with backoff and a checkpoint file so a crashed run can resume from the last completed stage.
- b. Extend the selection rules to include budget range, client rating, and deadline proximity as configurable thresholds.
- c. Add a dry-run mode that logs every decision and the would-be proposal text without actually submitting, for safe iteration on the rules.
— end of report —