RFP Hawk: an automated government-contracting intelligence machine

The brief

My own, and fully solo - every line of it. Government contracting is a discovery problem wearing a paperwork costume. Billions of dollars in opportunities post every week across SAM.gov, Grants.gov, and dozens of state procurement portals, each with its own interface, format, and login. Contractors either pay analysts to check portals daily or miss the bids they were built to win.

RFP Hawk turns that firehose into a matched, ranked feed. I designed, built, and operate the entire system: the scraping engine, the data model, the matching logic, search, billing, email, and the marketing site.

Building the acquisition engine

The core engineering problem is scale with sanity. Nobody can hand-maintain a scraper for every government portal in America - so I didn’t. The insight that makes RFP Hawk work: most state and local portals run on a handful of shared procurement platforms. Build one generic adapter per platform family - parameterized by tenant configuration - and one adapter suddenly covers dozens of agencies.

That architecture now spans seven platform families plus dedicated adapters for the major unique state systems (Texas, California, Florida, New York, and the rest) - roughly 250 registered adapter instances covering 180+ active sources, alongside the federal feeds from SAM.gov and Grants.gov. For the hostile portals - single-page apps, bot walls - a browser-automation tier handles what plain requests can’t.

Orchestration: built to fail gracefully

The whole machine runs itself on two automated daily runs. Every adapter gets a hard timeout, a records-per-run cap, a throttle, and an error threshold; every record is deduplicated by source ID and a content hash, so re-scraping can never create duplicates, and changed solicitations append to a revision log instead of overwriting history. One source breaking - and government portals break constantly - surfaces as a warning, never an outage. The system only fails if everything fails.

That’s the discipline I bring from marketing operations into engineering: the machine has to run every day without a human watching it.

The product layer

On top of the data sits the product a contractor actually touches: a three-step onboarding (company profile, NAICS codes, states), a dashboard of top matches scored 0–100 against that profile, full-text faceted search across the corpus, a five-stage drag-and-drop pursuit pipeline (Saved → Pursuing → Submitted → Won → Lost), a deadline calendar, CSV export, and daily or weekly digest emails that only send genuinely relevant matches - hard scope filters, agency diversity caps, and dedupe against everything already sent.

The matching engine is deterministic and transparent: NAICS overlap, geography, recency, and deadline windows produce the score. Behind it, an AI enrichment layer is built and cost-gated - extraction pipelines with per-record budgets and a fail-closed spending circuit breaker - engineered before the spend, ready to switch on as the corpus and customer base grow.

The marketing layer

Because I’m a marketer who ships software, the growth engine is in the codebase: programmatic SEO pages for every state, an industry taxonomy, a 30+ post content library, and a public data-sources transparency page. The product’s own data is its distribution.

Results

• 37,000+ solicitations tracked across 180+ active federal and state sources, refreshed daily on full autopilot
• ~250 adapter instances built on a platform-family architecture one person can maintain
• Complete commercial SaaS - auth, Stripe billing, digests, pipeline CRM, admin analytics - built entirely solo with AI-assisted development
• A running demonstration of the thesis behind everything I do: one operator, an AI-assisted workflow, and industrial automation can build what used to take a team