Multi-Platform Government RFP Monitor & Amendment Tracker — Python Developer

I'm launching a B2B subscription service that delivers civil construction bid intelligence to prime contractors and subcontractors across 27 US states. The core infrastructure of this business is a monitoring system that watches government procurement portals for new bid opportunities and alerts my team when something changes. I need an experienced Python developer to build this system from scratch using prototype code I've already written. This is not a spec-from-nothing project — the logic exists, the architecture is designed, and the platform types are fully mapped. Your job is to productionize, extend, and deploy. This is phase one of a growing platform with ongoing development work available as we expand states and add features. I am looking for a long term technical partner, not a one-time contractor. BACKGROUND ON THE BUSINESS We monitor 1,267 government agency websites across 12 launch states — Oregon, Washington, Idaho, Northern California, Central Valley California, Nevada, Utah, Montana, Arizona, New Mexico, Southern California, and Colorado — expanding to 27 states by end of 2027. Agencies include cities, counties, water districts, universities, airports, ports, transit agencies, and special districts. These agencies post civil construction bid opportunities on their websites using eight distinct procurement portal platforms. The system needs to watch all of them four times daily and alert us within minutes when something new appears. WHAT NEEDS TO BE BUILT Component 1: Multi-Platform RFP Page Monitor A scheduled monitoring system that checks all agency RFP listing pages four times per day — suggest 6am, 11am, 3pm, and 7pm Pacific — and detects when new bid listings appear or existing listings change. The eight platform types you will encounter and the required approach for each: Custom HTML (approximately 650 agencies) — standard scraping with requests and BeautifulSoup. Most straightforward. OpenGov (approximately 90 agencies) — investigate public API access before defaulting to scraping. OpenGov has a documented API that may provide cleaner data than page scraping. OregonBuys (approximately 40 agencies) — investigate API access first, fall back to scraping if needed. DemandStar (approximately 35 agencies) — investigate API access first. DemandStar has a vendor-facing API worth exploring. Bonfire (approximately 25 agencies) — investigate API access first, fall back to scraping. BidLocker (approximately 30 agencies) — investigate API access first, fall back to scraping. CivicEngage (approximately 45 agencies) — standard scraping, similar to Custom HTML. Biddingo (approximately 15 agencies) — JavaScript-rendered pages requiring Playwright or Puppeteer headless browser. Most technically complex platform on the list. Critical architecture requirement: build one scraper per platform type, not one scraper per agency. Every new agency on an existing platform must be addable via a configuration file with zero code changes. We add new cities regularly as we expand states and this must be a non-developer task. Component 2: Amendment and Addendum Tracker A second monitoring mode that watches specific project detail pages — not just the main RFP listing page — and detects when new document attachments appear. This is the amendment tracker. Many agencies post addenda and amendments as new PDF or Word document attachments on a project's individual detail page rather than as visible text changes on the main listing page. A plain text-change monitor misses these entirely. The amendment tracker watches the set of linked documents on a project page and alerts us when a new file link appears regardless of whether the visible page text changed. This runs as a separate monitoring mode on the same scheduling infrastructure as Component 1. When a project goes live and we begin tracking amendments, we add its detail page URL to the amendment tracker configuration. Same non-developer configuration requirement applies. Component 3: Alert System When either monitor detects a change, it sends an immediate alert containing the agency name, what changed (new listing title if detectable), the direct URL, the time of detection, and which monitor triggered it (new listing vs amendment). Alert delivery: email is required, SMS via Twilio is strongly preferred. We need both my email and my operations manager's email on all alerts. No auto-downloading. No auto-publishing. We receive the alert, manually visit the site, and decide whether to act. The system's only job is detection and notification. Component 4: Admin Interface A simple internal web interface — does not need to be polished, this is internal only — that allows non-technical team members to: View the current list of monitored URLs organized by state and platform type. Add or remove an RFP listing page from the monitoring list. Add or remove a project detail page from the amendment tracker. Switch a URL between monitoring modes. View a log of recent checks, changes detected, and alerts sent. See the current system status — when it last ran and whether any errors occurred. Flask or FastAPI is fine. Basic password protection required. Mobile-friendly layout preferred since we manage this from our phones. Component 5: Deployment The system must be deployed and running on a cloud server — AWS, DigitalOcean, or equivalent — before delivery is considered complete. I need a running instance, not just code. Include documentation for how to restart the system if it goes down and how to add new URLs without developer involvement. WHAT I'M PROVIDING Working prototype code covering the core page watcher logic in two modes — listing page text change detection and document link tracking. This is tested Python using requests and BeautifulSoup and includes the scheduling and alert framework. Complete agency list: 1,267 URLs across 12 states already researched and organized by platform type in a structured spreadsheet. This goes directly into your configuration files. Anthropic API key for any AI-assisted features. AWS S3 account already configured for document storage. Clear written requirements — this document — plus availability for daily communication during the build. TECHNICAL REQUIREMENTS Must have: Strong Python 3.9 or higher. Web scraping experience with requests, BeautifulSoup, and Playwright or Puppeteer for JavaScript-rendered pages. Experience deploying scheduled tasks or cron jobs on cloud infrastructure. Experience building lightweight internal admin interfaces with Flask or FastAPI. Clean, well-documented, maintainable code — this will be handed to future developers and must be readable. Strong preference for: Prior experience with government procurement portal scraping specifically. Familiarity with OpenGov, DemandStar, Bonfire, BidLocker, or Biddingo platforms. Experience investigating and integrating third-party APIs before defaulting to scraping. SMS integration experience with Twilio or equivalent. DELIVERABLES All source code in a private GitHub repository with clear README and setup instructions. Deployed and running instance on cloud server. Documentation for adding new URLs to both monitoring lists without developer involvement. A 30-minute walkthrough call on delivery so my team understands daily operation. Two weeks of post-delivery bug fixes included at no additional cost. PROJECT DETAILS Budget: $4,500-7,000 fixed price depending on approach and experience. Open to milestone-based payment structure. Timeline: Four weeks from start to deployed delivery. Start date: Immediate. HOW TO APPLY I will not consider proposals that do not answer all five of the following questions: One — describe a specific scraping project you have completed that involved multiple platform types or government procurement portals. What platforms did you handle and how did you approach sites that loaded content via JavaScript? Two — for the Biddingo platform which renders content via JavaScript, what tool would you use and why? Describe your specific approach. Three — for OpenGov, DemandStar, and Bonfire, do you have experience with their APIs? Would you attempt API integration before scraping and what is your reasoning? Four — propose a milestone breakdown for this project. How would you stage delivery so I can test Component 1 before you build Components 2 through 4? Five — what is your fixed price bid and realistic timeline to deployed delivery? Proposals that do not answer all five questions will be archived without response. I am not selecting on price — I am selecting on demonstrated understanding of the problem and relevant experience.