Python Playwright Developer Needed for Parallel Firefox Automation

I am looking for a highly experienced Playwright/Python developer to build a completely new browser automation project from scratch using Python, Playwright, and Mozilla Firefox. This is a new project and a fresh implementation. The architecture and browser workflow must be designed properly from the beginning for reliable parallel execution, strict browser isolation, API integrations, and performance. Main Requirements 1. Fresh / Virgin Browser Profile Every new workflow must start with a completely fresh browser profile/environment. Each new profile must have: * No previous cookies * No previous cache * No browsing history * No previous local/session storage * No previous authentication state * No reused browser profile data Each workflow must be isolated from all previous and parallel workflows. 2. Parallel Execution + Sticky Proxy Per Profile The script must work in parallel with multiple browser profiles running simultaneously. Each profile must receive one dedicated sticky proxy/IP. Requirements: * 1 profile = 1 proxy/IP * The IP must remain unchanged during the entire workflow * A single profile must not rotate through multiple IPs * New proxy assignment only when a new profile/workflow starts * No proxy/session sharing between workers * Parallel worker count must be configurable 3. Real Visible Mouse Interaction The automation must interact through the actual rendered browser UI. I need: * Visible mouse movement * Mouse movement toward elements before clicking * Standard mouse clicks * Scrolling when required * Keyboard input * Proper field focus * Normal navigation between fields and pages I do not want the entire workflow implemented using hidden DOM manipulation or direct JavaScript value injection. 4. Real Browser Interaction The workflow should reproduce the equivalent manual browser process as closely as practical. Actions should depend on the actual page state: * Wait until elements are visible and interactive * Click through the rendered UI * Type through browser keyboard events * Handle redirects and loading states properly * Handle dynamic elements correctly * Avoid fragile fixed-delay-only automation 5. Natural Interaction Behavior Browser interaction should have natural pacing and realistic UI behavior rather than performing every action instantly or using identical fixed timing for every workflow. The priority is to reproduce a stable, realistic manual-style interaction flow while maintaining good performance. 6. Browser Compatibility The automated browser must behave consistently with the normal manual browser workflow. The developer should compare the manual and automated flows and identify any automation-specific differences that cause functional problems. The solution must use supported browser functionality and should not depend on fragile hacks that make the project difficult to maintain. Strict Browser Isolation There must never be any leakage between browsers, profiles, or parallel workers. Each browser instance must remain completely independent, including: * Cookies * Cache * Local storage * Session storage * Authentication state * Proxy/IP assignment * Browser/profile data * Workflow state * API-related state Data from one browser/profile must never be accessible, reused, inherited, or accidentally shared with another browser/profile. This isolation must remain reliable even when many workflows are executing simultaneously. Manual vs Automated Workflow Consistency The automated workflow must reproduce the manual workflow as closely and consistently as technically practical. The developer must compare both processes carefully and ensure that automation-specific differences do not cause functional problems or unexpected account restrictions. The browser interaction sequence, navigation, form interaction, loading states, and required application state should remain consistent with the equivalent manual process. API Integrations The script will work with two external APIs. SMS API I will provide the SMS API and its documentation. The script must: * Request the required phone number/data * Assign it to the correct browser worker * Retrieve SMS verification codes * Submit the required verification information * Handle API errors and timeouts * Maintain completely independent SMS state for every parallel worker Email API I will provide the email API and its documentation. The script must: * Request/retrieve the required email information * Assign it to the correct browser worker * Retrieve required messages or verification codes * Handle API errors and timeouts * Maintain completely independent email state for every parallel worker SMS and email API state must never leak between workers. Parallel Performance & Capacity Study The developer must benchmark the application and determine the maximum stable number of parallel browser workers for the target environment. I do not want an arbitrary worker count. Concurrency should be progressively tested while measuring: * CPU usage * RAM usage * Browser process count * Average workflow duration * Success/failure rate * Network/proxy stability * SMS/email API response bottlenecks * Overall throughput Based on actual measurements, the developer must recommend the maximum stable parallel-worker count and explain why that configuration provides the best balance between performance, stability, and resource usage. Error Handling & Reliability The project must include strong production-level error handling. The script should: * Detect failures at each workflow stage * Log the exact failure reason * Handle timeouts cleanly * Handle proxy failures * Handle SMS/email API failures * Recover or retry when appropriate * Prevent one failed worker from affecting other parallel workers * Clean up browser processes and resources correctly Architecture The project should have a clean, modular architecture separating: * Browser/profile management * Proxy management * SMS API integration * Email API integration * Browser workflow * Parallel/concurrency management * Error handling * Logging * Results/output management Testing Requirements The developer must test the complete project independently before delivery. I do not want unfinished experimental versions repeatedly sent to me for testing. Testing must include: * Single-worker execution * Progressive parallel execution * Fresh-profile creation * Strict browser isolation * Sticky proxy/IP consistency * SMS API workflow * Email API workflow * Visible mouse/browser interaction * Manual-vs-automated workflow consistency * Failure recovery * Performance * CPU/RAM stability * Maximum stable parallel-worker count Developer Profile I am specifically looking for someone with strong practical experience in: * Python * Playwright * Mozilla Firefox * Browser automation * Parallel Playwright applications * Browser profile isolation * Proxy integration * Sticky proxy/session management * SMS API integration * Email API integration * Python concurrency * Performance optimization * Production automation debugging This is not a modification or patching project. I need a clean new implementation designed properly from the beginning. Please apply only if you have strong Playwright and Mozilla Firefox experience and can independently build, test, benchmark, and deliver a production-ready project. In your proposal, please include examples of similar Playwright projects and explain how you would approach browser isolation, sticky proxies, parallel workers, visible UI interaction, API integration, and concurrency benchmarking. Deadline & Important Notice The deadline for this project is 24 hours from the moment the contract starts. I have another project that needs to be developed immediately after this one. The second project is related to the same concept, so I would strongly prefer to work with one highly capable developer who successfully completes this first project, understands the architecture and concept, and can continue with me immediately on the second project. Please take the 24-hour deadline seriously and apply only if you are available to start immediately and prioritize this project. I am specifically looking for someone who already has strong practical experience with this type of Playwright architecture. Please do not apply if you intend to use this project to learn Playwright, experiment with technologies you have not worked with before, or repeatedly send me unvalidated AI-generated changes for testing. If your plan is to learn the technology or rely on trial-and-error AI-generated code during my project, please do not waste your time or mine by applying. I will hire only a developer who demonstrates that they already understand the technical requirements and can independently build, test, debug, and validate the project. The developer must perform their own testing before delivery. I do not want to be used as the project’s QA/testing environment. If this project is completed successfully, there is a second related project ready to start immediately afterward. Confidence Before Applying Please apply only if you are genuinely confident that you have the knowledge, experience, and technical ability to successfully complete this project. I am not looking for someone who wants to “try” or “see if it works.” I am looking for someone who already understands this type of Playwright architecture and is confident they can deliver the expected result. If you are not confident that you can successfully complete this project, I kindly ask that you do not apply. I would rather hire another developer than lose valuable time while discovering that the project cannot be completed. I am looking for a developer who takes ownership, solves problems independently, and can confidently deliver a production-ready implementation.