TI.com Inventory Monitoring & Checkout Automation Developer

Project Overview We are looking for an experienced developer to build a reliable, maintainable inventory-monitoring and purchasing-assistance tool for Texas Instruments (TI.com). This is not a one-time web scraping or Excel export project. We need a working application that continuously monitors selected TI part numbers and prepares purchases when our conditions are met. Our desired workflow is: Monitor selected part numbers → detect qualifying availability → recheck price and quantity → add the correct items to the TI.com shopping cart → fill in approved checkout information → notify the operator for final review. Phase 1 must stop before final order submission or payment. Unattended purchasing is not included in the initial scope. 1. Inventory Monitoring and Configurable Rules Provide a simple interface to add, edit, import and remove monitored part numbers, including CSV or Excel import. Use exact orderable part numbers, including all package and ordering suffixes. Do not substitute similar products automatically. For each part number, allow us to configure: - Desired purchase quantity and minimum available quantity. - Maximum acceptable unit price and currency. - Whether partial quantities are acceptable. - Monitoring priority and an enable/disable switch. Show the latest available stock, price, applicable purchase limits, last successful check and current monitoring status. Distinguish “out of stock” from failed requests, access restrictions or stale data. A monitoring failure must not be reported as zero stock. 2. Integration Approach and Feasibility First assess TI’s official inventory, inventory-notification and ordering APIs, including access approval, quotas and account eligibility. Use approved official integrations wherever practical. Any browser automation must be permitted by TI and remain within the applicable access conditions and limits. Our primary requested experience is TI.com website cart preparation and checkout autofill. Do not assume that API order creation is the same as adding items to the website shopping cart. Explain which parts of our desired workflow can actually be delivered. If website cart automation is not permitted or technically feasible, identify the blocker and propose an API-based approval workflow as a separately agreed alternative, not a silent replacement. 3. Automatic Cart Preparation and Checkout Autofill When stock and price meet our rules, revalidate the information before taking action. Add the exact approved part number and quantity to the cart. Respect purchase limits, minimum order quantities and applicable packaging requirements. Prevent duplicate additions caused by repeated notifications, retries or application restarts. Coordinate operations on the same cart and do not remove or modify unrelated items. Fill in information from approved company profiles, such as: company name, contact details, shipping address, billing address, and purchase-order or tax information where applicable. Use only information supplied and approved by us. Do not invent end-customer, end-use or compliance information. Pause for human intervention when login verification, CAPTCHA, additional declarations or other unexpected checks are required. Stop before final order submission or payment and notify the operator. The operator must be able to review and continue the prepared session. 4. Reliability, Dashboard and Alerts Design for continuous operation with configurable monitoring, controlled retries, rate limiting and recovery after interruptions. Handle expired sessions, API token renewal, timeouts, rate-limit responses, unavailable stock and unexpected page changes. For inventory subscriptions, handle initial stock checks, subscription renewal, expiry and duplicate notifications. Provide a dashboard showing monitored parts, current status, recent actions, failures and items awaiting manual review. Include start, pause, stop and emergency-stop controls. Send email alerts for qualifying availability, checkout readiness and failures requiring attention. Record timestamps so we can measure detection-to-action latency. Do not promise a refresh interval or monitoring capacity without explaining the applicable quotas and technical assumptions. 5. Security and Deployment Deploy the application in an environment controlled by us. Protect API credentials, login sessions and company information. Do not store payment-card security codes or expose secrets in logs. Explain whether the solution runs locally, on a server, or as a hybrid system, and how the operator takes over the checkout session. Disclose hosting costs, paid dependencies and recurring service fees. Bypassing access controls, purchase limits or security challenges, and using multiple accounts to evade restrictions, are outside scope. 6. Required Experience and Deliverables Strong experience with Python or TypeScript/Node.js, REST APIs, OAuth, webhooks and production automation is required. Playwright or equivalent browser-automation experience is relevant for any permitted browser-based components. Experience with TI integrations, electronic-component procurement, inventory monitoring or e-commerce checkout workflows is preferred. Experience diagnosing automation failures in Akamai-protected environments is useful, with appropriate escalation or human handoff. Deliver complete source code, dependency specifications, configuration examples, deployment instructions, user documentation, automated tests and a demonstration of the agreed workflow. We require maintainable source code, not only a compiled executable or a tool that depends on an undisclosed developer-owned service. 7. Proposal and Initial Milestone Please include: - Relevant projects or a redacted demonstration. - Your proposed API/browser architecture and required approvals. - Any limitations affecting TI.com cart and checkout automation. - Expected monitoring capacity and measurable latency assumptions. - A milestone-based quote, delivery schedule and maintenance terms. Start with a small paid feasibility milestone using a few agreed part numbers. Demonstrate monitoring, rule evaluation and the permitted purchase-preparation workflow before full development. Test restock transitions and failures using mocks or available official test facilities where appropriate. Do not place real orders during testing without our explicit approval. We are looking for an experienced Python web data extraction and browser automation engineer to develop a maintainable website monitoring system. Required experience: 1. Python web scraping and data extraction 2. Playwright, Scrapy, Puppeteer or Selenium 3. Login sessions, cookies and authorized account workflows 4. Product price, inventory and availability monitoring 5. Scheduled tasks, retries, logging and failure alerts 6. Data export to API, CSV, Excel or database 7. Docker deployment and technical documentation 8. Website structure change detection 9. Experience troubleshooting automation compatibility in environments protected by Akamai Bot Manager 10. All work must be limited to websites, systems and accounts for which we have authorization, and must comply with applicable terms, rate limits and privacy requirements. The developer must deliver complete source code, deployment documentation, logging, monitoring and test cases.