They wanted answers they could check
Dominik Müller, Maximilian Pfestorf and Carlos Gienow — Dominik, Carlos and Max, as they sign their posts — kept running into the same wall. Company and personal knowledge lives everywhere: PDFs, mailboxes, drives, tickets. The AI tools sitting on top of that pile give you two choices, and both are unsatisfying: retrieve a pile of text chunks, or let an agent search through MCP and API calls and guess. It's slow, it burns tokens, and you can't always tell where an answer came from.
That's the origin story Dominik told on launch day, and it's unusually concrete for a founder post. The team didn't start with a market thesis about knowledge graphs. They started with a personal frustration: they wanted answers they could check. When the answer matters — a contract clause, a decision trail, a fact your agent acted on — 'the model probably found it' is not good enough. So they built yggy to turn that mess into a knowledge graph that builds itself.
The insight worth naming is that they automated the parts of graph building that make most teams give up. Per the site's own description, yggy's Core takes over the recurring work of extraction, modeling, entity matching and updates — the exact chores that kill knowledge-graph projects in month two. Nobody launches a graph pilot and fails at the demo; they fail at the months of data modelling and ontology design that follow. yggy's bet is that this work should be the product, not the homework.
Breaking a lot of graphs
Three days before launch, Dominik posted a short hello in the Product Hunt forum: 'Almost there.' The team had spent the previous months, in his words, turning messy PDFs, mailboxes, drives and tickets into knowledge graphs that build themselves. Then came the sentence that makes the whole post worth reading: 'Along the way we broke a lot of graphs and merged things that should never have been merged.'
That line is doing real work. Entity merging is the unglamorous, failure-prone core of any knowledge graph — decide that 'Acme' and 'Acme Inc.' are the same entity, and you've corrupted every downstream answer if you're wrong. By admitting the breakage happened during development, the team is quietly telling you two things: they hit the hard part instead of demoing around it, and they survived it. The fix they describe — every fact links back to where it came from, merges can be undone — reads like a direct response to those months of wreckage.
It's also a small masterclass in pre-launch communication. No roadmap promises, no 'AI-powered revolution' boilerplate. Just: here's the messy problem, here's what broke, here's how we made it survivable. On launch day the team stayed in the comments all day answering questions — the forum post had already set the tone of makers who'd rather debug than pitch.
What the graph does by itself
The product's core loop is deliberately boring, which is the point. First, you bring data in: upload documents, connect your systems, or push data through the API. Then yggy does the structuring — it reads everything, extracts entities and relations into your ontology, merges duplicates, and links every fact back to its source. No schema to design, no pipeline to run. The tagline on Product Hunt says it plainly: 'The AI knowledge graph that builds itself.'
What makes this interesting is the fixability layer, which the team lists among its core values. Merges are reversible, and unclear cases go to a review queue where domain experts define the meaning and decide the ambiguous ones. That's a meaningful design choice: instead of pretending the automation is perfect, the system assumes it will sometimes be wrong and builds the correction into the workflow. Every answer points to where it came from, and you can see what yggy did and why.
The ontology stays compliant rather than improvised — facts land in a structure the team and the customer define together, not a pile of loose text. This is the difference between a graph and a search index: structure you can reason over, with provenance you can audit. For teams that need to know why the answer is the answer, that distinction is the whole sale.
One graph, three doors
One graph, three doors. That's the consumption story, and it's the part that positions yggy as infrastructure rather than another chat window. Your team asks questions in the app; your code builds on the REST API; your agents plug the graph in through MCP. One structured source of truth, consumed by humans, programs, and agents alike.
The dev-first value is explicit: REST API, MCP, a CLI and SDKs, with docs written for builders. Multi-tenant and secure rounds it out — every organization and project is isolated, with SSO, scoped API tokens and an audit log. And for the note-takers, there's a lighter sibling: 'Just want your own notes in a graph? We built yggy notes for exactly that.'
Then there's the hosting line that doubles as a positioning statement. EU-hosted, GDPR-first: 'Your knowledge stays yours.' In a market where most knowledge tooling runs on US infrastructure with murky data flows, geography becomes a feature. The company behind it is Yggdrasil UG — the name nods to Yggdrasil, the Norse world tree that connects everything, which is about as on-the-nose as a knowledge-graph brand gets.
Why knowledge graphs, why now
yggy launched on Product Hunt at #20 for the day with 79 points and 70 followers — a solid, workmanlike debut for infrastructure software, tagged across Productivity, Developer Tools and Artificial Intelligence, with a launch deal of 25% off for three months. Not a viral spike; a builders' launch for a builders' product.
The deeper story is why the timing works. The whole industry is currently discovering that agents are only as good as the knowledge they can trust. Every team wiring agents into their operations hits the same sequence: first the demo with a few documents, then the realization that retrieval guesses and burning tokens on MCP spelunking don't survive contact with real decisions. Knowledge graphs are the old, unfashionable answer to that problem — and the reason they stayed unfashionable was the months of manual modelling. A graph that builds itself, where every fact keeps its source and every merge can be undone, removes the historical objection.
Whether yggy wins its category is still an open question — it launched this week. But the team has picked the right fight: not 'chat with your documents' prettier, but the infrastructure layer underneath it, built by people who broke enough graphs to know where the bodies are buried.
The playbook
- Automate the part that makes people give up — yggy's pitch is that Core takes over the recurring work of extraction, modeling, entity matching and updates — the grind that kills graph projects before they ship.
- Ship the trust mechanism, not just the output — Every fact links back to where it came from, and you can see what yggy did and why. Trust is the product, not a checkbox.
- One graph, three doors — One graph serves the team in the app, the codebase through the API, and agents through MCP. Build once, consume everywhere.
- Log the breakage in public — Their pre-launch forum post admitted they'd broken a lot of graphs and merged things that should never have been merged. Technical honesty reads as credibility on launch day.
- Launch dev-first, not deck-first — REST API, MCP, a CLI and SDKs, with docs written for builders — the launch treated developers as the primary customer from day one.
- Make hosting a selling point — EU-hosted and GDPR-first turns geography into a feature: 'Your knowledge stays yours' is the line, not a legal footnote.