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.

Using Replit as a Working Room

Late last year, a mathematician friend of mine showed me what he’d been building in Replit, an AI-powered software development platform. Although it usually takes me some time to find the thread, when my friends show me something they are excited about, I usually try to find a way to apply the concept to some area of my life. The more disparate the concepts, the more fun.

So in April, I decided to experiment with Replit in my ops work. I have no illusions or interest in suddenly becoming a full-stack engineer (for one, true engineering takes more skill than teaming up with an AI agent). Certainly not as a misguided, shiny AI productivity hack. More like this: What if the messy middle of my operations work had somewhere to go?

I wanted to play with this question because that is usually where my work lives (and my books). Not the project plan or the final deliverable. Or the carefully formatted strategy deck. Where does the brain matter and communication live BEFORE the tidy SOP is complete? From my experience, it’s usually in the strange, unfinished space between:

“This is overwhelming.”

“I know something isn’t working.”

“We have too many tools.”

“I don’t know where to look.”

“I keep explaining the same thing.”

“We need a system, but I don’t know what kind.”

Untangling these spaces begins as a walk through fog. There are so many inboxes, spreadsheets, sticky notes, half-built CRMs, un(der)documented habits, abandoned tools, workarounds, screenshots, and a thousand small decisions living inside someone’s head. Traditionally, I would turn that fog into a documented audit: maps, process notes, recommendations, roadmaps, implementation plans. That piece is still critical for unscrambling the noise. But lately, I’ve been asking a different question: What if the less visible “messy middle” could become a space?

The experiment

For a few recent client projects, I’ve been using Replit to build simple, working environments to visualize the operational problems we’re trying to solve. It’s not a software product, but a lightweight digital workbench for seeing ops clean-up prototypes and the decision-making that lives with the process.

My goal was to build a place where the client can see the entire landscape of the work: What we’ve uncovered, pending decisions, available options, the phase we’re in, and what might happen next.

For one client, that has meant creating a visual hub for a healthcare practice operations project: intake, communication, scheduling, billing, portal decisions, workflow pain points, and vendor comparisons.

For another, it has meant creating a clearer container for a very human problem: too much information spread across too many places, with no single place to re-enter the work when the brain gets overloaded. That second part matters to me because many operational systems fail not because people are careless or lazy, but because they require too much reorientation every time someone returns to them. A good system should reduce the energy cost of engaging with them.

Why Replit has been interesting

Replit is useful to me right now because it lets me move quickly from “here’s what I’m seeing” to “here’s something we can look at together.” This connective tissue changes the direction of the conversation and gives it focus. Instead of sending a client a long document and hoping they can hold the whole system in their mind, I can build a small interface that says:

• Here is the current state.

• Here are the pressure points.

• Here are the options.

• Here is the next decision.

• Here is what we are not doing yet.

It makes the invisible parts of operations more visible, and because the work is still rough, editable, and alive, it invites an iterative approach to feedback. In this way, the people I partner with do not have to respond with a final answer to an abstract concept…they can engage in meaningful dialogue with a visual model. And I get usable data! Rather than hearing, “I don’t like that” or “I’m not sure I need that,” I get to hear:

“That’s not quite how it works.”

“This step actually happens before that one.”

“We don’t need that yet.”

“That is the thing that stresses me out.”

“This is the part I need to see every week.”

It tells me not just what the process is, but also how the people I work with EXPERIENCE the process. For me, this distinction is everything.

The app is not the point

I’m trying to be careful here, because it would be easy to overstate the technology. The Replit build is not the transformation. The app is not the strategy, and the prototype is not the operating system. It is a room where the work can become visible. That’s all.

But “that’s all” is not small.

When a team, founder, or practice owner is carrying the operational complexity in their head, visibility is often the first real relief. Before automation, there has to be understanding. Before optimization, there has to be orientation. Before implementation, there has to be a shared picture of what is actually happening. That is where these experiments have been useful, letting me create something that lives in the space between a document and a system… a place to collaboratively test assumptions. And ask better questions.

What I’m learning

I’m learning that humans often do not need MORE information; they need a path to understanding the mountain of information they already have access to. That means supporting the creation of hierarchy, sequencing, and containerization. From there, prioritization becomes second nature, and they can let the systems they create do what they do best: Minimize chaos and decision fatigue.

I’m also learning that prototypes reveal friction faster than documents do because written recommendations can sound good but are often too abstract. They also leave out a population that ingests and understands information differently. Putting recommendations into a clear structure — even a very simple one — quickly surfaces gaps in understanding and resources.

What’s Next?

So the next frontier is (yet) another question: What happens when we stop treating operations as back-office cleanup and start treating these engagements as design material?

My interest lies in testing whether operational thinking can be mobilized through lightweight tools at the intersection of human and tech intelligence to improve the efficacy of decision support. The right tool for the moment can shape behavior and influence outcomes. It can hold criteria steady when your brain is tired and reveal patterns that were scattered.

I don’t yet know exactly how Replit will fit into {improbable.}’s tool ecosystem long-term. Right now, I’m treating it as an experiment in operational sense-making. Some of my experiments may become reusable templates. Some may remain on the cutting room floor. For now, Replit has proven to be a fun place to text what’s possible.

That feels worth paying attention to.