Ideator: Using Knowledge Graphs to Let AI Tell You What Product to Build

Entrepreneurs validating an idea typically open twenty browser tabs, scour app stores and Reddit, and end up with a competitor list—yet still don't know what to build for v1. Chat assistants don't solve the problem either: ask the same question twice and you may get completely different answers.

Developer Ronak Sarda submitted a project called Ideator during the second week of the Hacktoberfest open-source AI challenge, attempting to turn "competitor research" into "actionable product-building decisions." Its core idea: turn search results into a knowledge graph, let a Gemma agent reason over that graph, and ultimately produce a build brief with sources.

From a Competitor List to a Five-Slot Decision Brief

Using Ideator is simple: the user enters an idea in one sentence, and the system runs three real-time searches in parallel—Google for competitors, Google Play for real app names and pricing, and Reddit for user complaints. Gemma cleans the raw results into structured records and writes them into the FalkorDB graph database.

Each session has its own graph, with nodes for companies, prices, features, and grievances. A Gemma agent then queries the graph step by step through MCP tools, and every response ends with a five-slot build brief:

Slot	Meaning
Who pays	The precise paying audience
What pain it solves	The one grievance you fix, with the number of people who raised it
Why you win	Your advantage relative to named competitors
Pricing	A dollar price with rationale (from the TabPFN model)
V1	v1 delivers only 2–3 things; everything else is out of scope

The "pain" and "pricing" slots are auto-filled from evidence, while the user decides the other three; Ideator asks about each in turn and offers evidence-based suggestions. After a few rounds, the user has a complete brief; the action plan tab provides a paragraph-form plan and a numbered build order, and every user quote can be clicked back to its source.

Graph Reasoning: Finding the "Unanswered Complaint"

The most interesting technical design of this project is modeling market research as multi-hop queries on a graph. The Cypher query that carries most of the work looks for feature gaps that multiple competitor users complain about but that your idea does not yet address:

MATCH (u:UserIdea {id: $idea})-[:TARGETS]->(c:Competitor)
      -[:DRAWS_COMPLAINT]->(g:Grievance)
      -[:TARGETS_FEATURE]->(f:Feature)
WHERE NOT (u)-[:SOLVES]->(g)
RETURN f.name, count(DISTINCT g), collect(DISTINCT c.name)
ORDER BY count(DISTINCT g) DESC

When the user iterates on the idea based on feedback, the new version gains a SOLVES edge, and the same query naturally shifts to the next unmet need. This approach—recording decisions and their evidence in the graph structure—is what sets Ideator apart from ordinary AI assistants: decision nodes carry BECAUSE edges pointing to grievances and features, and users can click a decision on the visual map and trace along the edges all the way back to the original Reddit post.

During execution, the agent selects MCP tools step by step: market overview, multi-hop grievance hotspots, feature PageRank, community detection, evidence paths, and TabPFN price prediction. Each step streams onto the interface in natural language, and the graph map highlights the region currently being queried.

Cypher is a declarative query language designed by Neo4j for property graphs, and FalkorDB is compatible with a subset of its syntax. Its core is MATCH pattern matching: using ASCII diagrams like ()-[]->() to describe paths of nodes and edges, on which the database performs multi-hop traversals rather than joining tables like SQL. The NOT (u)-[:SOLVES]->(g) in the query above is a negative pattern match that excludes grievances already covered by the current idea—a direct expression at the query level of the semantics of "finding gaps." Cypher also supports count(DISTINCT ...) aggregation, collect() to fold multiple rows into a list, and ORDER BY sorting, so a single query can simultaneously aggregate grievance heat and bring back named competitors. For an agent, the value of this language is that a single tool call returns structured, explainable multi-hop evidence, without the model having to stitch together multiple single-hop queries itself.

How the Open-Source Model Stack Supports the Product

Ideator is built almost entirely on open-source or open-weight components, which is both a technical choice and a source of product resilience.

Gemma-driven agent loop. The project uses gemma-4-26b-a4b-it and gemma-4-31b-it to run the agent loop and write reports. When hosted endpoints fail, short prompts fall back to gemma2:2b on local Ollama; if all models are unresponsive, the report is built from search data alone and clearly states so.

TabPFN for pricing and crowdedness scoring. Each analysis copies competitors into a shared market_history graph, and the predict_price tool trains a TabPFN regressor on the spot at call time—the more it's used, the more accurate the price estimates become. Another tool feeds graph counts into a TabPFN classifier to score market crowdedness.

FalkorDB and MCP. The graph database is isolated per session, PageRank and community detection are built-in capabilities, and the MCP Python SDK wraps graph queries as tools that the agent picks step by step through an MCP client.

The author admits in the post that open weights literally saved the product: during the build, the hosted Gemma endpoint repeatedly returned errors, and it was precisely because the model was open-source that it could fall back to local Gemma and keep responding, rather than showing users an error page.

TabPFN is a class of Transformer-based "tabular foundation models" whose approach is the opposite of conventional supervised learning: it is pretrained on massive synthetic tabular datasets and learns the learning algorithm itself—"given a small batch of labeled samples, how to make Bayesian-style predictions for new samples." As a result, there is no traditional training loop or hyperparameter tuning: feed in the training set as context, and a single forward pass yields predictions, often called "in-context learning" or in-context learning for tables. Its applicable boundaries are clear: it performs best with sample sizes typically within a few thousand rows and feature counts within the hundreds, which matches Ideator's scenario of accumulating only dozens to hundreds of competitor records per session. What the post calls "training on the spot at call time" is essentially re-reasoning each time with the current graph counts or price samples as context—the benefit is that new data takes effect immediately with no model version to maintain, at the cost of one forward-pass overhead per call.

MCP (Model Context Protocol) is a protocol proposed and open-sourced by Anthropic to expose external tools and data sources to models/agents through a unified interface. It uses a client-server structure: an MCP server declares a set of tools with JSON Schema (name, parameters, description), the MCP client injects these tool descriptions into the model context, and the model requests a tool via a structured call, which the client executes and returns results for. Compared with hardcoding tools into prompts or business code, MCP's advantage is that tools can be deployed independently, reused, and swapped, and agents can "discover" capabilities on demand. Ideator's MCP Python SDK wraps capabilities such as Cypher queries and price prediction into individual tools, and the agent chooses which one to call each round—which also explains the "step-by-step tool selection" and the step-by-step streaming interaction on the interface: each tool call is an observable protocol round trip.

Lessons Learned: Prompt Constraints Are Weaker Than Code Constraints

The most valuable part of the retrospective is the list of specific failures and fixes.

The most typical one: the author asked Gemma in the prompt to "always check grievances and pricing before answering," but the model sometimes skipped steps and answered directly. Eventually this rule was moved into code (REQUIRED in tools.py), so the agent cannot finish until both tools have run. This detail shows that for current models, process constraints are more reliable in the code layer than in the prompt layer.

Another issue was the hosted Gemma continually returning 500 errors, rooted in JSON mode combined with minimal thinking settings; the author resolved it by no longer requiring JSON mode and parsing answers themselves.

There was also a rather self-aware finding: reviewing the demo recording frame by frame, the author noticed that the market map listed an NFL discussion thread and a TV show as competitors to a certain logging tool—search results had never been relevance-checked. The fix was to add keyword validation and discard results unrelated to the idea.

On performance, Ideator is not instant: a new idea takes about one to two and a half minutes, because real-time search and agent steps take real time; follow-up questions are faster.

PageRank and community detection are two classic algorithms in graph analysis, and FalkorDB provides them directly as built-in procedures, so there is no need to export the graph to an external computing framework. PageRank was originally used for web ranking, with the intuition that "a node pointed to by important nodes is also important." In Ideator's context, it can rank feature nodes and measure how much of a "hub" a feature is in the overall competitor network—the more competitors and grievances jointly involve it, the more attention it deserves. Community detection (such as Louvain-type algorithms) clusters tightly connected nodes to identify "the same group of features the same batch of users complain about," i.e., potential niche markets or product categories. Combined, the two let the agent answer "what feature clusters exist in this market, and which are core" without relying on model guesswork—instead it gets reproducible numerical evidence from graph algorithms, which is then combined with complaint counts from multi-hop queries to form a mutually corroborating evidence chain.

Privacy Boundaries and the "Side Hustle" Path

A founder's unannounced idea is sensitive information. Ideator's stance is that open weights mean the model reading your idea need not be a rented black box; the graph database and tool server both run locally, and falling back to local Gemma via Ollama is already supported. But the author honestly draws the boundary—search still goes through SerpApi, price prediction goes through Prior Labs, and full localization is a direction rather than the current state.

The first users were a few of the author's college friends, who tried it with their own ideas on the author's machine and said they'd each pay around 2,500 rupees to use it—though no actual payment has occurred yet. When the author told them the project is open-source and can be self-deployed for free with BYOK (bring your own key), the response was "then ship it": add a login page and paywall and start charging. That forms the next step of the side-hustle plan.

The most convincing feedback came later: inspired by Ideator, a friend ran his own idea through it and then launched an ERP agent project for his school called Praesentia, handling grades, courses, and related matters.

The Full Tech Stack

Beyond the core components, Ideator uses Temporal to run search and report generation as durable workflows with retries (the agent loop itself is not inside the workflow); Sentry records one transaction per conversation, with one span each for every Gemma call and MCP tool call; ElevenLabs provides a read-aloud button for any response. The backend is FastAPI with server-sent events, and the frontend is vanilla JavaScript with Cytoscape.js.

Notably, the project is candid about its own limitations: the agent loop is not managed by Temporal, search and pricing are not yet localized, and response times are measured in minutes. In a field full of narratives about "fully automated AI startup assistants," this restrained engineering self-account better illustrates the system's actual capability boundaries.

For indie developers, product managers who need pre-meeting briefs, accelerator mentors reviewing many ideas each week, and students who want to avoid reinventing the wheel, Ideator offers clear value: it doesn't give you yet another competitor list—it forces you to make a decision in five slots, and every slot can be clicked back to its evidence. The plan can also be exported as an AGENTS.md file and dropped directly into Claude Code or Cursor, so a coding agent starts from established decisions rather than a blank prompt.

One-line Summary

Ideator uses a knowledge graph plus a Gemma agent to turn competitor research into a traceable five-slot product-build brief.

Paragraph Summary

Ideator is a project submitted by developer Ronak Sarda for the Hacktoberfest open-source AI challenge, aiming to transform startup idea validation from "flipping through twenty tabs to get a competitor list" into "actionable product-building decisions." The system searches Google, Google Play, and Reddit in parallel, cleans results into structured records, and writes them into a FalkorDB graph database, with each session having its own graph. A Gemma agent queries the graph step by step through MCP tools and uses multi-hop Cypher queries to locate feature gaps that multiple competitor users complain about but that your idea hasn't yet addressed, ultimately producing a five-slot brief covering who pays, what pain it solves, why you win, pricing, and v1 scope—with every conclusion clickable back to its original source. The tech stack is built almost entirely on open-weight components; TabPFN handles pricing and crowdedness scoring, and a local Ollama fallback saved the product when the hosted endpoint failed. The author's core lesson: process constraints are more reliable in the code layer than in the prompt layer.