Win The Opportunity

Win The Opportunity uses AI Agents to discover funding opportunities matched to your mission, extracts the application questions, and helps you craft winning answers — all in one place.

Comment

Inspiration

The inspiration came from a simple but painful observation: NGOs spend an enormous amount of time on administrative busywork instead of doing their actual mission work.

Every NGO I thought about faces the same grind:

  • Hunting for grants across dozens of websites, newsletters, and databases.
  • Reading each opportunity to figure out if it's even relevant to their mission.
  • Re-filling the same questions over and over — "Organization name," "Country," "Contact email," "Describe your project" — across every single application.
  • Missing deadlines because there's no central place to track them.

NGOs answer the same questions repeatedly for different funders. If we could use AI Agents to find the opportunities, extract those questions automatically, generate answers based on the NGO missions and previous work, and build a reusable backlog of answers, we'd save NGOs hundreds of hours.

I wanted to build a system where the background work happens automatically. The AI agents that scrape, match, and extract, and provide answers to the application, so the NGO just sees a clean dashboard of "here are the opportunities that fit you, and here are the answers to the questions for each opportunities and edit if need be you'll need to answer."

What it does

Win The Opportunity is an AI-powered agentic platform that helps NGOs discover, manage, and craft winning applications for grants, scholarships, and fellowships. Instead of NGOs spending weeks manually hunting for funding and filling out repetitive application forms, the platform automates the entire pipeline — from discovering opportunities to extracting application questions and answer those questions.

How we built it

Architecture

┌─────────────────────────────────────────────────────────┐
│                    Frontend (Vue 3)                     │
│              Tailwind CSS · navy + gold                 │
└──────────────────────────┬──────────────────────────────┘
                           │ HTTP (JWT)
┌──────────────────────────▼──────────────────────────────┐
│                    Backend (FastAPI)                    │
│        Users · Orgs · Opportunities · Applications      │
│        Recommendations · Onboarding · Auth              │
└───────┬──────────────┬──────────────┬───────────────────┘
        │              │              │
        ▼              ▼              ▼
   Scraper        Recommender    Application-Scraper
   Agent          (RAG/Chroma)   Agent
   (Playwright + LLM)   (Gemma LLM)    (Playwright + LLM)

The stack

  • Backend: FastAPI, SQLAlchemy 2.0, Pydantic v2, Alembic migrations, JWT auth
  • Frontend: Vue 3, Vue Router, Tailwind CSS, axios
  • Agents: Strands Agents SDK, OpenRouter (LLMs), Playwright (web scraping), ChromaDB + sentence-transformers (RAG)
  • Package management: uv for Python, npm for the frontend

The six-agent vision

The full system is designed around six agents:

  1. Opportunity Scraper — finds grants/fellowships on the web.
  2. Recommender — matches opportunities to NGO profiles (vector + LLM).
  3. Application Form Scraper — extracts questions from application forms.
  4. Vision/Screenshot — reads forms via screenshots when HTML fails.
  5. Answering — drafts winning answers to questions.
  6. Evaluation — scores and improves answers.

The onboarding flow

A new NGO signs up → fills in their organization profile → clicks "Get my recommendations" → the system matches opportunities to their mission and extracts application questions → they land on a dashboard of personalized recommendations.

Challenges we ran into

2. Repeated recommendations

The recommender kept recommending the same opportunities. I fixed it with an "exclude already recommended" pattern — tracking which opportunity IDs were already recommended to each user, rather than relying on last-run timestamps.

3. Timezone bugs

Comparing naive vs. aware datetimes caused subtle bugs in the recommender's "new opportunities" window. The fix was normalizing all datetimes to UTC.

4. Service authentication

Agents needed to call the backend without a user JWT. I implemented a service API key mechanism (X-API-Key header) alongside user JWT auth, with a ServiceOrUserDep dependency that accepts either.

5. JS-rendered application forms

Most real application forms (Submittable, Microsoft Forms, Google Forms) are JavaScript-rendered — the questions aren't in the static HTML. This is why we built the extraction_reason field: a user-friendly explanation of why questions couldn't be extracted (e.g., "This form requires you to log in before the questions are visible").

Accomplishments that we're proud of

A working end-to-end platform where an NGO can:

  1. Sign up and tell us about their mission.
  2. Instantly get personalized grant recommendations daily with relevance scores.
  3. See the application questions extracted from real forms.
  4. Build a reusable backlog of answers to save time on every future application.

The background agents do the heavy lifting — the NGO just sees the results.

What we learned

This project was a deep dive into agentic AI systems and multi-service architecture. Some of the biggest lessons:

1. Agentic systems are pipelines, not magic

The "AI" isn't one thing — it's a pipeline of specialized agents, each doing one job well:

  • Scraper Agent — discovers opportunities from the web.
  • Recommender Agent — matches opportunities to an NGO's profile using hybrid vector + LLM scoring.
  • Application-Scraper Agent — visits application forms and extracts the questions.
  • ** Answering Agent** - that answers the questions to the application forms
  • Evaluation Agent - that evaluates the answers

2. Standalone services communicate over HTTP

Each agent is a separately deployable service (a sibling folder to the backend) that talks to a FastAPI backend over HTTP. This taught me a lot about service boundaries, API design, and authentication between services (service API keys vs. user JWTs).

3. Local embeddings + vector search are powerful

The recommender uses ChromaDB with local sentence-transformers embeddings — no cloud vector database needed. This keeps the system self-contained and private.

4. Real-world forms are messy

The biggest reality check: most application forms are JavaScript-rendered or behind authentication. Extracting questions reliably is genuinely hard. This shaped the design — we capture a reason when extraction fails, so the user understands why.

5. Deployment

Used the following AWS Services: Lambda, Fargate, EventBridge, Amplify, ECR, Bedrock, etc.

What's next for Win The Opportunity

  • Agents 4–6: Vision (screenshot reading), Answering (drafting), Evaluation (scoring).
  • Answer submission: wiring up editable answers in the application workspace.

Built With

Share this project:

Updates

Submission history