SignalForge

An evidence-first radar that turns fast-growing open-source signals into explainable, testable SaaS opportunities with OpenAI.

Comment

Inspiration

GitHub Stars are a useful signal of developer attention, but they are not proof of customer demand or revenue. I wanted a research system that could continuously watch open-source momentum, separate hype from durable evidence, and turn that evidence into testable product hypotheses for independent developers, startup teams, and innovation researchers.

What it does

SignalForge is an evidence-first open-source opportunity radar. It:

  • discovers fast-growing and recently active repositories through the GitHub API and OSS Insight;
  • stores time-stamped SQLite snapshots so 24-hour, 7-day, and 30-day momentum can be measured instead of inferred from lifetime Stars;
  • separates deterministic trend, commercial-opportunity, evidence-confidence, and human-review signals;
  • classifies repository type, license risk, commercialization maturity, Issue demand, and maintainer responsiveness;
  • suppresses noisy candidates such as lists, demos, templates, mature commercial products, and restricted model or dataset projects;
  • optionally uses GPT-5.6 structured outputs to turn compact evidence bundles into industries, buyers, pain points, SaaS directions, monetization, moats, risks, and confidence;
  • includes Signal, a streaming GPT-5.6 research copilot that can compare opportunities, explain scores, and create customer-validation plans from the current radar or selected project;
  • preserves a deterministic local analysis path when OpenAI is disabled or unavailable; and
  • presents the evidence in an accessible Apple HIG-inspired workspace with English, Simplified Chinese, Traditional Chinese, desktop, and mobile layouts.

How we built it

The backend is TypeScript on Node.js 22 using Node's built-in SQLite support and native fetch, with no runtime npm dependencies. GitHub Search and Repository APIs provide primary metadata, while OSS Insight contributes an external 24-hour signal. A scheduled pipeline normalizes repositories, preserves source URLs and capture times, calculates multi-window momentum, enriches strong candidates with README and Issue evidence, and produces explainable score components.

The OpenAI integration uses the Responses API in two bounded server-side paths. gpt-5.6-luna produces JSON Schema-constrained analysis for the strongest candidates. gpt-5.6-sol powers the Signal copilot with streamed text, a compact source-aware context, bounded conversation history, no tools, and store: false. Repository content is labelled as untrusted evidence, and prompts require the model to distinguish facts, inference, and recommended validation.

The Web client is dependency-free HTML, CSS, and JavaScript. It provides responsive research cards, detailed evidence sheets, keyboard shortcuts, focus management, reduced-motion support, loading/empty/error states, and three complete language catalogs. Docker packages the API and worker. Deterministic tests and a versioned opportunity-ranking benchmark protect collection, scoring, persistence, API contracts, assistant streaming, localization, accessibility, and failure behavior.

How we used Codex and GPT-5.6

Codex was the primary development workspace. It helped inspect the existing codebase, maintain versioned execution plans, implement server and UI changes, add regression tests, run the quality gates, and control Chrome for desktop, mobile, keyboard, focus, and submission QA. Work was kept in small reviewable commits, while product decisions, credentials, merging, legal acceptance, and final submission stayed under human control.

GPT-5.6 is not only part of the build process; it is a product capability. The structured-analysis path converts verified public evidence into explicit commercial hypotheses. The interactive Signal copilot then helps a researcher question that evidence without hiding uncertainty. If no API key is configured, SignalForge remains usable through its deterministic evidence and scoring engine.

Challenges we ran into

The hardest challenge was preventing an attractive number from becoming an unsupported conclusion. Stars can be old, manipulated, or disconnected from business demand. Mature projects may already have paid offerings, Issue text can exaggerate one complaint, external signals expire, and GitHub rate limits interrupt enrichment.

SignalForge addresses those problems by preserving provenance, separating measured, external, and estimated momentum, requiring multiple signals for stronger demand claims, decaying stale evidence, and keeping facts, deterministic scores, AI inference, and human decisions distinct. The assistant follows the same evidence boundary instead of acting like an unrestricted chatbot.

Accomplishments that we're proud of

  • A working discovery, enrichment, scoring, analysis, persistence, API, dashboard, and research-copilot pipeline.
  • Explainable trend and opportunity scores with stored components and evidence confidence.
  • Commercialization and Issue-demand evidence that reduces false opportunities.
  • A graceful deterministic fallback when OpenAI is unavailable.
  • A professional three-language interface with responsive and accessible interaction paths.
  • Reproducible offline quality gates that never call paid APIs or live GitHub collection.

What we learned

Confidence is not the same as score. A high score based on estimated growth should not outrank a slightly lower score backed by fresh snapshots and multiple sources. AI is most useful when it converts a well-structured evidence bundle into explicit hypotheses; it should not invent the evidence or hide uncertainty. A useful copilot also needs strong interaction design: clear context, visible limitations, keyboard access, predictable focus, and a safe fallback matter as much as the model call.

What's next for SignalForge

Next I will expand the human-reviewed benchmark, add competitor and pricing-page validation, introduce custom watchlists, and generate one-page validation cards with interview questions, MVP boundaries, and pricing hypotheses. The longer-term plan is a Flutter iOS and Android client that consumes the existing versioned API, supports offline review, and keeps credentials and collection jobs off-device.

Source code and testing instructions are provided in the submission's Additional info section.

Share this project:

Updates