Refactor GM Scraper Core
Budget: €8 – €30 EUR
=> Brief
Project 1 — Refactoring AI Local Lead Automation for Marketing Agencies (GM Scraper) into a Generic Browser Automation Core
Purpose
Conversion of GM Scraper from a Google Maps-specific tool to a generic browser automation core with Facebook Tasks as the first use case.
=> Project summary
We want to reshape the existing GM Scraper so that it ceases to be a Google Maps-specific automation app and becomes the proper foundation for a broader web-based execution product.
We want a clean generic browser automation core, on top of which other platform modules can be gradually added.
The first practical use case of the new core will be Facebook Tasks, along with REST API, Webhooks, and connection to StackPosts.
=> Main goal
The existing GM SCRAPER needs to be transformed from a Google Maps-specific automation / scraping application to a generic browser task execution platform.
The new platform must be able to accept commands from UI and/or API, execute browser-driven tasks, store structured results, logs and artifacts, and be extended later with new platform adapters without changing the core architecture.
Technological base that must be maintained
• Angular front-end
• Node / Express backend
• Playwright
• Crawlee / PlaywrightCrawler
• database / persistence layer
• existing auth / settings structure
• Project Scope 1
• • Project 1.a — First functional base of the new generic core with the first active adapter, Facebook Tasks.
• • Project 1.b — Complete integration layer with REST API, Webhooks and StackPosts connector.
Indicative Facebook Tasks within scope
• Account connection / session handling
• Check account status
• Retrieve basic page / profile data
• Get list of posts
• Create post / scheduled post
• Upload media
• Reading comments/messages where legal and authorized
• Collection of notifications / activity logs
• Return screenshots / execution logs / structured output
Architectural direction
The new core must stop relying on Google Maps-specific concepts, such as search results, maps scraping, leads campaigns, and cron-based Google Maps flows.
Instead, it should be built with neutral concepts like Platform, Platform Account, Browser Profile, Task Template, Task Run, Artifact, Execution Log, Webhook Event, and Integration Connector.
Indicative key entities
platforms
platform_accounts
browser_profiles
task_templates
task_runs
task_run_logs
artifacts
webhook_subscriptions
api_tokens
integration_connectors
What needs to be implemented in Project 1
Refactored back-end
Refactored database schema
Updated Angular admin UI
Facebook adapter
Task runner / worker-ready execution flow
REST API
Webhook system
StackPosts connector
API documentation
Setup instructions
Migration instructions
Execution model
The execution flow should not remain a simple cron-based runner. We want task queue, worker-based execution, state transitions, retries, structured logs, screenshots / artifacts, timeout handling and recoverable failures.
Admin UI
The Angular UI needs to stop being Google Maps-first and become a generic admin panel with basic sections like Dashboard, Accounts, Browser Profiles, Tasks, Runs, Artifacts, Webhooks, Integrations, and Settings.
What should not be done?
• Do not attempt to implement all platforms together now.
• Don't let the architecture become deeply tied to StackPosts.
• Do not leave Google Maps-specific schema names in the shared core.
• Do not provide a one-off Facebook patch instead of a reusable adapter.
• Do not add misleading traffic/engagement modules.
Short deliverable acceptance list
• The core is no longer Google Maps-first.
• Facebook has been implemented as the first adapter on top of the generic core.
• There are task queue / worker logic, statuses, logs and artifacts.
• There are REST APIs, Webhooks, and StackPosts connectors.
• The UI allows basic management of accounts, tasks
Required Developer Qualifications
• Strong knowledge of Node.js/Express
• Experience in Angular
• Experience in Playwright / browser automation
• Experience in REST API and Webhooks
• Experience in database refactoring and migrations
• Experience in queue / worker architecture
• Logic of modular and scalable system design
• Ability to rebuild an existing codebase into a reusable platform core
Access, deliverables and follow-up
Access: Access to Plesk will be provided for working on the real server.
Repository: The project should be kept in a GitHub repository and we should be able to pull changes via SSH when needed.
Proof of operation: Each core deliverable must be accompanied by working code, demonstration videos, screenshots, and brief technical documentation.
Project 1 — Refactoring AI Local Lead Automation for Marketing Agencies (GM Scraper) into a Generic Browser Automation Core
Purpose
Conversion of GM Scraper from a Google Maps-specific tool to a generic browser automation core with Facebook Tasks as the first use case.
=> Project summary
We want to reshape the existing GM Scraper so that it ceases to be a Google Maps-specific automation app and becomes the proper foundation for a broader web-based execution product.
We want a clean generic browser automation core, on top of which other platform modules can be gradually added.
The first practical use case of the new core will be Facebook Tasks, along with REST API, Webhooks, and connection to StackPosts.
=> Main goal
The existing GM SCRAPER needs to be transformed from a Google Maps-specific automation / scraping application to a generic browser task execution platform.
The new platform must be able to accept commands from UI and/or API, execute browser-driven tasks, store structured results, logs and artifacts, and be extended later with new platform adapters without changing the core architecture.
Technological base that must be maintained
• Angular front-end
• Node / Express backend
• Playwright
• Crawlee / PlaywrightCrawler
• database / persistence layer
• existing auth / settings structure
• Project Scope 1
• • Project 1.a — First functional base of the new generic core with the first active adapter, Facebook Tasks.
• • Project 1.b — Complete integration layer with REST API, Webhooks and StackPosts connector.
Indicative Facebook Tasks within scope
• Account connection / session handling
• Check account status
• Retrieve basic page / profile data
• Get list of posts
• Create post / scheduled post
• Upload media
• Reading comments/messages where legal and authorized
• Collection of notifications / activity logs
• Return screenshots / execution logs / structured output
Architectural direction
The new core must stop relying on Google Maps-specific concepts, such as search results, maps scraping, leads campaigns, and cron-based Google Maps flows.
Instead, it should be built with neutral concepts like Platform, Platform Account, Browser Profile, Task Template, Task Run, Artifact, Execution Log, Webhook Event, and Integration Connector.
Indicative key entities
platforms
platform_accounts
browser_profiles
task_templates
task_runs
task_run_logs
artifacts
webhook_subscriptions
api_tokens
integration_connectors
What needs to be implemented in Project 1
Refactored back-end
Refactored database schema
Updated Angular admin UI
Facebook adapter
Task runner / worker-ready execution flow
REST API
Webhook system
StackPosts connector
API documentation
Setup instructions
Migration instructions
Execution model
The execution flow should not remain a simple cron-based runner. We want task queue, worker-based execution, state transitions, retries, structured logs, screenshots / artifacts, timeout handling and recoverable failures.
Admin UI
The Angular UI needs to stop being Google Maps-first and become a generic admin panel with basic sections like Dashboard, Accounts, Browser Profiles, Tasks, Runs, Artifacts, Webhooks, Integrations, and Settings.
What should not be done?
• Do not attempt to implement all platforms together now.
• Don't let the architecture become deeply tied to StackPosts.
• Do not leave Google Maps-specific schema names in the shared core.
• Do not provide a one-off Facebook patch instead of a reusable adapter.
• Do not add misleading traffic/engagement modules.
Short deliverable acceptance list
• The core is no longer Google Maps-first.
• Facebook has been implemented as the first adapter on top of the generic core.
• There are task queue / worker logic, statuses, logs and artifacts.
• There are REST APIs, Webhooks, and StackPosts connectors.
• The UI allows basic management of accounts, tasks
Required Developer Qualifications
• Strong knowledge of Node.js/Express
• Experience in Angular
• Experience in Playwright / browser automation
• Experience in REST API and Webhooks
• Experience in database refactoring and migrations
• Experience in queue / worker architecture
• Logic of modular and scalable system design
• Ability to rebuild an existing codebase into a reusable platform core
Access, deliverables and follow-up
Access: Access to Plesk will be provided for working on the real server.
Repository: The project should be kept in a GitHub repository and we should be able to pull changes via SSH when needed.
Proof of operation: Each core deliverable must be accompanied by working code, demonstration videos, screenshots, and brief technical documentation.