We want to enhance the targeting of lead searches in Google SERPs by dynamically incorporating location context into queries. This improves relevance when customers are seeking leads tied to a specific city, region, or country. Current Approach Given a keyword, the system searches Google using structured operators, for example: "keyword" site:facebook.com "@gmail.com" Enhancement If a $location object is available, containing: city name country name search engine’s SERP locale settings …then augment the query to reflect location targeting, so the SERP results are more geographically relevant. Examples: "keyword in Barcelona" site:facebook.com "@gmail.com" "keyword in Spain" site:facebook.com "@gmail.com" Location-Optimized Operators and options to maximize results Add quotes around "in {location}" to ensure exact match in Google. Use OR to merge variations when possible, for example: "keyword in Barcelona" OR "keyword in Spain" site:facebook.com "@gmail.com"

Appends location keywords like "NYC" or "Barcelona" to search queries when GPS data is ambiguous, providing a fallback to improve precision.

Goal: Refine and implement a robust algorithm to compare results between old and new software versions, with clear documentation of how the tool works. DoD: Write clear documentation explaining the existing comparison logic. Review and challenge the current approach to identify improvements. Implement the updated algorithm in code. Validate that the new algorithm detects meaningful differences (quality, quantity, relevance). Ensure output is reliable and easy to interpret.

Goal: Create a dashboard to track and display the quality of each search by comparing old and new software results, clearly showing which version performs better. DoD: Displays each search with old vs. new results side by side. Shows a quality rate or score per search. Clearly indicates the “winner” for each search.

Improve export functionality by adding filters such as minimum accuracy percentage and lead type, allowing users to generate more targeted and relevant export files.

Goal: Uses Hunter company profiles to discover new domains and extract additional contact emails, expanding coverage beyond existing sources. Notes: Define criteria for when Hunter should be used (e.g., missing domain, incomplete contact info, cross-checking company details). Cache all data retrieved to avoid repeated lookups and reduce load. Explore ways to access Hunter data without a paid API plan (scraping, proxy APIs, Apify, etc.). Perform initial tests to measure usefulness and overlap with current data sources. DoD: Implement integration with Hunter (API or alternative method). Define rules for when Hunter is triggered. Add caching layer for retrieved company profiles. Run tests and document results (quality, quantity, overlap).

Goal: This version combines two high-quality data sources — Google Maps (strong targeting, good business categorization) and YellowPages (broad coverage, including businesses not indexed or ranked highly on Google). Notes: To get as close as possible to the results of LeadScrape, we will implement a new generator that is based on both sources of data. https://app.asana.com/0/profile/1190504173282355 needs to suggest a clever way to fetch data from both source to take the best of both. YellowPages doesn't offer any API so we need to find a way to have one, ApiFy is an option. DoD: Implement a new generator Make some tests and show the results

Goal: Implement a basic user management system to identify and track who is using the tool, enabling better usage monitoring, access control, and activity logging. DoD: Basic login (hard-coded users). The list of users should be a dropdown so everyone easily what to choose. No password, we just use a username for tracking purposes. Per-user concurrency limit: max 3 parallel requests. Dashboard updates: show lead “owner” and add filter. User base: preload all IG managers + ViscaWeb employees. No roles/permissions yet (all free access).

Goal: Adapt the project’s architecture to support higher concurrency, increasing the number of simultaneous crawls from the current limit (~5) to up to 20, enabling faster data processing without performance degradation. Technical information: The project is limited by two processes: Running generator Fetching external websites About running generator: This process is quite light, it's just about fetching some APIs. We could increase the number of // requested to 20 instead of 5. About fetching external websites: This one eats much more memory, even though I don't have exact numbers. The generator sometimes asks to fetch 100 websites, so we must ensure this part has many workers. DoD: Increase the fetching by 4 to 5. Documentation explaining how things works. When fetching external content: persist in database which workers have been in charge. Add a monitoring to ensure supervisor health. Questions to reply to: Are we to implement a solution like supervisor to make it easier rather than running cronjobs? How to run the fetching external websites workers onto another server? How to keep the current system as straight-forward as possible, ideally by not having two apps (one for the current software, one for fetching websites)?

Goal: Given a keyword, we already crawl Google results, visit each site, and extract leads (e.g., emails). We want to extend this flow to assign each lead a relevance percentage based on the email itself and the content/context of the page where the lead was found. Core Features: Accuracy calculation: Compute a percentage score for each lead. UI integration: Show the score in the listing of leads. Export exclusion: Accuracy score must not appear in exports (CSV, XLSX, JSON, etc.). Approach (AI-driven): Use AI via online APIs to determine lead relevance. Prompts: Add a new case in the “Prompts” section. Inputs may include: email, keyword used for crawling, page content (HTML or PDF), location. Output: A structured accuracy percentage (0–100%), potentially with flags or reasoning. DoD Validate edge cases manually Create a documentation accordingly Implement the algorithm accordingly Add a new column in the leads table

Finds extra contact emails by scanning publicly accessible Google Docs and PDFs, with deduplication.

Goal: The main goal here is to prevent things to break, so we will adopt a preventive approach. Therefore, the most important to us is to make sure everything is healthier and will stay healthier.

Goal: Replicate Google Maps searches from the old software to the new one by automatically enqueueing the same queries, ensuring data consistency during migration. DoD: Automatically detects and downloads search queries from the old software. Enqueues identical searches in the new software. Monitored for performance impact and adjusted if needed.

I have found an issue (not really an issue) regarding the platform, but an important aspect, I realised we are missing something, so I dig a bit in the current process (with the old tool) and I remember, that one of the point is to decide either if we find B2C or B2B leads. Based on that, together with the platform, the query for Google is the email domain to look at, for example, if its B2C, we use @hotmail, @gmail and so on… it’s a part of the query that (attachment 1); And finally, for each email domain, the system uses the definition of B2C and B2B emails domains as defined on this guideline (attachment 2), the email guidelines to use are on page 13, look on the PDF for the “Domain extensions to use”. We have to implement the B2B/B2C (not adding a selector) but as a part of LeadGenerator and then, adding the b2c email domain selection OR b2b email domain selection based on the search parameters.

Goal: Develop a system that generates common or inferred email addresses for a given domain (e.g., contact@domain.com, info@domain.com, or firstname.lastname@domain.com) and verifies their existence using email verification APIs. The goal is to enrich incomplete lead data by intelligently guessing potentially valid email addresses and confirming their deliverability. DoD: Identify and document common email patterns (generic + name-based) Integrate with a reliable email verification API (e.g., ZeroBounce, NeverBounce, MailboxValidator) Mark guessed emails as “verified” or “undeliverable/unknown” based on API response

Reintroduction of the Google Maps Scrapper enhanced with our custom email finder (that finds more emails by browsing the website).