Context
Pokelo is our own product — and the tool we wished we already had. Every project ran into the same thing: knowledge about the product lived in a dozen places at once. Part of it sat in the README, some decisions were buried in a chat thread, the reason a particular database was chosen lived in one person’s head, and the rest had to be reconstructed from commit history.
While the team is small and stable, you get away with it. The trouble starts when someone new joins, when you come back to the code six months later, or when a client asks “why was it built this way?”. The answer exists — nobody just knows where.
We built Pokelo because we wanted project context to be a single place, not the sum of what people happen to remember.
Problem
Scattered knowledge costs the most exactly when you least expect it.
- Documentation lives apart from decisions. You know what was built, but not why — and the “why” (the technical decisions, the ADRs) usually matters more.
- Onboarding turns into archaeology. A new person spends their first days digging through files, asking around, and piecing the whole picture together from fragments.
- Knowledge evaporates with people. When someone leaves a project, they take context that was never written down anywhere.
- Plain search isn’t enough. You can find the file that contains the word “authentication”, but not the answer to “how does our login work, and why without bank passwords”.
This isn’t a problem of missing documentation. It’s a problem of documentation, decisions and context not being connected — and not being something you can query like a person who simply knows the project.
Solution
Pokelo keeps documentation, technical decisions (ADRs) and project context in one place — and links them into a knowledge graph. Instead of a flat list of files you get a network of relationships: a decision knows which part of the product it concerns, a document knows which decision it relates to, and context ties it all together.
On top of that graph sits AI. This is the heart of the AI-first approach: the model isn’t a chatbot bolted onto a knowledge base — it’s how you use the knowledge base in the first place.
- You ask in plain language and get an answer with context. Not “here are 12 files matching your query”, but a concrete answer grounded in what the project actually decided.
- Onboarding built on the graph, not on digging through docs. A new person asks Pokelo the way they’d ask a teammate — and gets an answer along with its source.
- Decisions have a home. ADRs aren’t loose notes; they’re graph nodes linked to what they affect.
AI should support the process, not replace thinking. In Pokelo, AI is built into a real process — managing project knowledge — rather than tacked on as a gadget.
Under the hood Pokelo runs on Nuxt 4 and Node.js, with an LLM layer handling search and conversation with the knowledge graph. The product is live at pokelo.bearly.pro.
Outcome
Pokelo is a product we build and use ourselves, so we describe the results qualitatively, without inflated metrics.
- A single source of truth. Documentation, technical decisions (ADRs) and project context sit in one place and are searchable by AI — instead of being scattered across files, notes and people’s heads.
- Faster answers. Instead of hunting for whoever remembers a decision from six months ago, you ask Pokelo and get an answer grounded in the project’s facts.
- Smoother onboarding. A new person gets into a project through a conversation with the knowledge graph, not through lonely digging.
- Knowledge that stays. Context stops leaving with people — it settles somewhere everyone can reach.
For us, Pokelo is also proof of how we think about AI: a tool that earns its keep, built into a real process rather than dressed up as a flashy add-on with no substance.