Senior Python & Playwright Developer — Production-Ready Automation System

I’m looking for a senior Python developer with strong Playwright experience to build a complete, production-ready multi-account email automation and account-management system. This project requires real engineering experience with: * Python * Playwright * SMTP * App-password authentication * Browser automation * Concurrency * Worker pools/schedulers * Persistent state * Network/proxy configuration * Error recovery * Long-running automation The system will be used only with accounts and credentials that I am authorized to use and must comply with applicable provider policies and restrictions. Important — Playwright Is Required Playwright is a mandatory part of this project. The developer must be experienced with Python Playwright and capable of building reliable browser automation where browser interaction is required for authorized account-management or provider-specific workflows. I do not want Selenium or another browser framework substituted unless I explicitly approve it. The Playwright implementation must be properly engineered and should include, where applicable: * Reliable browser/context lifecycle management. * Multiple-account session handling. * Persistent or isolated browser contexts where appropriate. * Cookie/session management. * Timeout handling. * Navigation failure handling. * Browser crash recovery. * Element/state waiting using proper Playwright methods. * Clean retry logic. * Screenshots/debug artifacts for genuine failures where useful. * Resource-conscious operation when several account workflows are running. * Clean shutdown and restart handling. The developer should not rely on fragile fixed sleep timers when Playwright can properly wait for page, locator, navigation, request, or state conditions. Playwright should be integrated into the overall application architecture rather than delivered as a disconnected secondary script. Email / SMTP System The application should support a configurable pool of authorized email accounts and SMTP configurations. It should include: * SMTP authentication. * App-password authentication where supported. * Multiple SMTP/provider configurations. * TLS/SSL. * Secure credential handling. * Account rotation. * Configurable sending limits. * Persistent per-account counters. * Configurable parallel processing. * Resource-aware worker management. * SMTP connection management. * Retry handling for temporary failures. * Authentication-error handling. * Rate-limit handling. * Lead/recipient queue management. * Duplicate-processing protection. * Detailed logging and monitoring. The system must never intentionally circumvent provider restrictions, anti-abuse protections, account limits, or applicable policies. Account Daily Sending Limit Each account must maintain an independent configurable sending limit. The required default value is: per_account_daily_limit=500 The application must: * Track successful SMTP-accepted sends for each account. * Enforce the limit centrally. * Prevent parallel workers from exceeding the limit because of race conditions. * Stop assigning new leads to an account immediately once it reaches its configured limit. * Remove that account from the active sending pool. * Record it in 24-reached.txt. * Maintain the appropriate timestamp/state. * Keep the account unavailable during its configured cooldown. * Restore eligibility automatically when appropriate. * Preserve all counters/state after application restart. Failed authentication attempts, failed connections, and other unsuccessful SMTP operations must not simply be counted as successful sends. Scheduler & Dynamic Concurrency I do not want a hard-coded worker count such as 10 accounts. The developer must design a proper scheduler/worker architecture. Concurrency should be configurable and should consider: * Number of active/eligible accounts. * Maximum parallel accounts. * Maximum SMTP connections. * CPU utilization. * RAM utilization. * Current SMTP connections. * Browser/Playwright resource usage. * Provider limits. * Configured safety margins. * Per-account sending state. Configuration should support settings such as: max_parallel_accounts max_parallel_smtp_connections cpu_limit memory_limit batch_size per_account_daily_limit retry settings timeout settings delay settings The server has substantial available resources, including 128 GB DDR4 ECC RAM, but the application must still use controlled and intelligent concurrency rather than simply opening an excessive number of browser instances or SMTP connections. The developer must document how concurrency is calculated and controlled. Required Files config.txt General configuration including: * Sender name. * Subject. * Per-account limit. * Parallel-account limit. * SMTP connection limit. * CPU limit. * RAM limit. * Worker/batch settings. * Retry settings. * Timeout settings. * Delay settings. * Template selection. * Playwright settings where applicable. * Other application settings. I want to be able to maintain multiple .txt configuration profiles and select which configuration to run. app_passwords.json This is the primary structured credential file. It will contain authorized account/app-password information. Credentials must be securely handled and must never be unnecessarily exposed in logs. accounts.txt Main authorized account list. One account per line. leads.txt Recipient list. One recipient per line. Recipient processing state must be persistent enough to prevent accidental duplicate processing after worker/application failures. letter.html HTML email template. It should support configured sender information, subject, links/buttons, and documented placeholders. links.txt Links available to the template. 24-reached.txt Human-readable record of accounts that have reached their configured sending limit/cooldown state. Playwright Account Management Where an authorized provider workflow requires browser interaction, the account-management component should use Python Playwright. The developer should design this as a proper module integrated with account state and logging. Where supported and permitted by the relevant provider, this may include authorized account-management operations such as updating account settings or credentials. These functions must be implemented properly and tested rather than included as placeholders. Any provider-specific operation must respect the provider’s policies and supported workflows. Network / Proxy Configuration If network/proxy support is needed for the deployment environment, it should be configurable and properly integrated with both relevant Playwright and network components. The implementation should include, where applicable: * Proxy configuration. * Account/network mapping. * Proxy authentication. * Timeout detection. * Connection-failure detection. * Controlled retry/recovery. Network or proxy functionality must not be designed to circumvent provider restrictions, sending limits, security controls, or anti-abuse protections. Persistent State & Restart Recovery This application must maintain reliable state during long-running operation. Restarting or crashing the application must not: * Reset account counters. * Reactivate accounts still in cooldown. * Cause an account to exceed its configured limit. * Accidentally process the same recipient as a completely new recipient. * Lose important scheduler/account state. The developer must design concurrency-safe state management. Logging Logging should cover: * Successful SMTP-accepted sends. * Failed sends. * SMTP errors. * Authentication errors. * Rate-limit responses. * Per-account counters. * Account status. * Cooldown state. * Playwright errors. * Browser/session failures. * Network errors. * Proxy errors where applicable. * Recipient processing. * Worker status. * Resource utilization. * Scheduler status. Credentials and sensitive authentication data must not appear in logs. Reliability This is a production application, not a temporary script. It should properly handle: * Network interruptions. * SMTP disconnects. * Browser crashes. * Playwright timeouts. * Temporary provider failures. * Invalid credentials. * Application restarts. * Worker crashes. * Individual account failures. * Resource pressure. * Large account lists. * Large recipient lists. An individual account or worker failure should not unnecessarily stop the entire application. Code Quality I expect: * Clean Python architecture. * Proper module/class separation. * Clean Playwright architecture. * Proper scheduler/worker design. * Robust exception handling. * Secure credential handling. * No hardcoded credentials. * No unnecessary dependencies. * Installation instructions. * Configuration documentation. * Usage documentation. * Maintainable source code. * Meaningful comments where required. * Proper testing before delivery. VERY IMPORTANT — NO UNTESTED AI-GENERATED CODE Please read this carefully before applying. I am not looking for a developer who generates large amounts of code with ChatGPT, Claude, Copilot, or another AI tool and immediately sends the code to me without properly understanding or testing it. Using development tools to assist your own work is not the issue. The problem is developers who: 1. Generate code they do not fully understand. 2. Send it to the client without testing it. 3. Ask the client to run it. 4. Wait for the client to send an error. 5. Generate another patch from that error. 6. Repeat this process indefinitely. I will not accept this development method. Do not repeatedly send me messages such as: “Please test this version and tell me what error you get.” or “Try this code and send me the traceback.” as your primary method of developing the project. I am hiring a developer, not acting as the developer’s testing environment. You are expected to: * Understand the existing requirements before implementing. * Design the architecture properly. * Run the application yourself during development. * Test the important workflows yourself. * Reproduce and debug problems yourself whenever technically possible. * Inspect your own logs and errors. * Fix your own implementation. * Test again after the fix. * Deliver a stable version only after you have performed proper development testing. Of course, final provider-specific verification may require credentials/configuration that I will supply when appropriate. However, basic development, debugging, syntax validation, architecture validation, worker testing, Playwright testing, SMTP testing, state testing, and error-handling testing are the developer’s responsibility — not mine. I do not want an unfinished AI-generated prototype delivered as a completed milestone. Testing Before Delivery Before considering the project ready for delivery, the developer must test: * Application startup. * Configuration loading. * SMTP authentication. * Playwright workflows. * Browser/session handling. * Multiple-account processing. * Concurrent worker behavior. * Per-account limit enforcement. * Race-condition protection. * Account cooldown. * Restart recovery. * Recipient state. * Temporary SMTP errors. * Authentication failures. * Browser failures. * Worker failures. * Graceful shutdown. * Logging. The delivered project should be a version that the developer has already run and tested. Delivery Final delivery must include: * Complete source code. * All required modules. * Playwright implementation. * SMTP implementation. * Scheduler/worker system. * Persistent state handling. * Example configuration. * Installation instructions. * Dependency requirements. * Configuration documentation. * Usage instructions. * Architecture explanation. * Tested final version. When Applying Please include: * Your Python experience. * Your Playwright experience. * Your SMTP/email-system experience. * Your experience with large multi-account applications. * Your experience with asyncio/threading/multiprocessing. * Your experience building schedulers and worker pools. * Your experience with persistent state and concurrency. * How you would design the dynamic concurrency system. * How you would safely enforce per-account limits with multiple parallel workers. * How you would prevent duplicate recipient processing after a restart. * How you would integrate Playwright into the application architecture. * Examples of comparable production systems you personally developed. Do not apply if your plan is to generate the project with AI, send it to me untested, and use me to discover and debug every error. I am looking for a senior developer who can take ownership of the architecture, implementation, testing, debugging, and final delivery.