Building OpportunityOS in Replit: An Experiment in Making the Ops of Work Search Visible
The origin of OpportunityOS was less a polished roadmap and more a confrontation with a fundamental systems problem. I craved a clearer interface to see the work I’ve been pursuing; not just the discrete tasks, but the whole, fluid, messy ecosystem of possibility. For too long, my wily environment of freelance projects, government RFPs, consulting leads, key contacts, and all the tiny decisions that sit between a "curious oddity" and "worth pursuing" has been scattered across my inboxes, spreadsheets, “productivity” apps, and analog tools.
Functionally, opportunity has not reliably existed anywhere…functional.
Thus began a microtest with Replit. This move was not about suddenly "building software" (I’ll leave that magic to the experts). I’d already been experimenting with the tool to bring visibility and accountability to the process of working with {improbable.} for my client partners. Over the past seven months, I spent time reading conversations from across the labor market—the frustrated job seekers and burned-out recruiters describing fragmented, opaque systems. Amidst this noise, I found a post on Reddit from a developer about an app they built called OpenPostings, aimed to solve some of these frustrations from the job seeker’s POV. This served as a trigger for a specific systems question for me: Could I build an interface for OpenPostings that shows me jobs relevant to my skills? Or better yet, could I bring RFPs, freelance gigs, and traditional roles into a single place?
That was the start of OpportunityOS—not a strategy, but a question: What if opportunity-searching had an operating system? For me, building out this idea was about assembling a rough version of the thing I wished existed.
The experiment is simple:
Collect relevant opportunities in one place, evaluate them against criteria (such as fit, urgency, strategic value, and energy cost), decide whether to pursue the opportunity, and track progress.
Replit has turned out to be the perfect testing ground, allowing me to iterate (messily) in a container. The true operational pain lies in the human, often hidden/autopilot, parts of our systems… where the process is memory, the criteria are instinct, and the follow-up is a hopeful lapse. OpportunityOS is my attempt to externalize that logic, just enough to reduce the complexity that leads to overwhelm when pursuing opportunities for work.
Like any good experiment, parts of it immediately failed.
The direct integration with OpenPostings proved stubbornly difficult. Once I let go of my rigid expectations about which integrations to use, the build began to unfold. I ended up using the JSearch API (via RapidAPI) for job listings, my SAM.gov API key for federal solicitations, and will add Upwork for freelance gigs once my API key request is approved.
I quickly learned that while my ChatGPT architecture companion, Quill, was excellent for strategy and translation, the work needed to be done closer to the app's environment. The switch to a Replit agent taught a crucial lesson about AI-assisted building: the question is never "which tool is best?" but "which tool is best for this part of the work?"
This cross-pollination of W2 jobs, freelance leads, and government contracts is transforming the prototype from a mere tracker into a personal opportunities operating system.
Currently, OpportunityOS is a tiny command center for juggling multiple potential revenue streams.
Instead of a frantic, panic-scrolled existence across job boards and spreadsheets, everything is organized into a single prioritized, AI-powered pipeline. Right now, the core capabilities include:
Unified Pipeline: All opportunity types (W2 roles, 1099 contractor gigs, and GovCon/RFP solicitations) are tracked in a single List-style pipeline. Each opportunity card surfaces its status, type, deadline urgency, and a composite priority score so I know what to work on next.
AI-Powered Scoring: Every opportunity is scored across five dimensions: Fit, Effort, Risk, Cash, and Strategic value. These combine into a single Priority Score (0–100) that automatically ranks my pipeline. The Re-Score feature re-evaluates all scores using GPT-4.1 against my uploaded resume, replacing generic defaults with scores personalized to my actual experience and skill set relative to the opportunity.
Multi-Channel Import: Opportunities can enter the pipeline by pasting a job description, dropping in a URL, uploading a PDF or DOCX, or connecting directly to live sources such as SAM.gov (federal contracts), JSearch (aggregates Indeed and LinkedIn), and soon, Upwork. The system extracts and normalizes every import into a consistent structure.
AI Workflows: The Actions tab provides five ready-to-run AI workflows: Write Proposal, Draft Outreach, Bid/No-Bid Analysis, Daily Briefing, and Archive & Debrief.
Document Library: A central knowledge base where I store my professional documents. Each workflow reads my Document Library, which is intended to hold my resume, brand identity, capability statement (for govcon), and work portfolio, to produce drafts that utilize my voice.
Contact CRM: A lightweight CRM for tracking the people connected to my pipeline, like hiring managers, contracting officers, and client contacts. Contacts are linked to opportunities and tracked with relationship stages and proposed outreach dates.
Live Source Connectors: The Sources tab connects to external APIs that automatically push new opportunities into my pipeline. API keys are stored per-connector inside the app.
The next two weeks…
…are dedicated to using the system to refine the API calls; filtering federal opportunities by specific NAICS codes, removing old postings, and improving alignment. I will be building a practical feature list based on friction and utility, deciding what needs to be automated and what should remain a part of the slog that is so beautifully, uniquely human. OpportunityOS is not finished, but it is a working experiment in operational visibility. It is a way to bring the search out of the inbox and browser tabs and into a system I can actually use. The most {improbable.} part of this experiment is not that I built something, but that I stopped waiting for the perfect system and started making the invisible one usable.
