Should I vibe code
Internal wiki and knowledge workflows integrated with team chat
A bot answering in a channel is not a search result. It is your company saying something, in front of twelve people.
?
Their verdict, the Scaling price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Three team wikis already sit on this site and all three make the same opening point: the documents are the easy half. Take it as read. What is different about Tettra is the direction of travel. Its centre of gravity is not the wiki, it is the bot in chat — questions arrive as Slack messages, answers get posted back into DMs and channels, and old answers already buried in Slack can be mined into the knowledge base. Two consequences follow that a homemade version reliably gets wrong. First, a reply in a channel has an audience rather than a reader: filtering retrieval by whoever asked does nothing when the answer lands in front of everyone in the room, and Slack has already pushed the full text to a dozen phones by the time you think about deleting it. Second, a corpus made of answers rots differently from a corpus made of documents. Somebody's off-hand reply from 2024 becomes canon, gets re-served with a bot's authority, and — if you built the mining feature — gets ingested back in as evidence that it is the answer. Tettra ships three separate reports whose entire job is to tell you the corpus has rotted: stale pages, unowned content, public content. That loop is the product. The editor is not.
What actually breaks
not "if". the specific failures.
- The reply, the moment it lands in a channel. Deleting a Slack message is one click and it recalls nothing — the notification preview already delivered the full text to everyone with the app installed
- Permission filtering, which almost everyone implements against the asker and nobody implements against the audience. Correct in a DM, a broadcast in a channel
- The bot token, which needs history scopes across the workspace to do any of this — a key to the entire company's conversation, living in an environment file on a box you alone administer
- The corpus, once it is made of answers rather than documents. The first plausible reply becomes canonical and nothing in the system can mark a better one as superseding it
- Ingestion from chat, which imports material nobody wrote for publication: a pasted key in the engineering channel, an address in operations, a conversation that was awkward the first time
- Freshness, structurally — no owner, no verified-on date, and in eighteen months an archive nobody trusts and nobody is willing to delete
- Slack's request signing and its three-second acknowledgement deadline, which is exactly where homemade bots start double-posting answers
- Public sharing and external sites, which put an internal page on the open web with a crawler's memory attached to it
The question in the general channel is an ordinary one: what is the refund window on annual plans? The bot answers in nine seconds, in the channel, with total composure, drawing on a page written by somebody who left in 2024. Sixty days — which was true until finance changed it to thirty in the spring and wrote a new page nothing connects to the old one. A support engineer reads the bot, tells a customer sixty days, and puts it in an email. You find out on Thursday when the customer replies with the screenshot. Deleting the bot's message takes a click and achieves nothing: eleven people saw it, four had it delivered as a phone notification containing the whole answer, and one repeated it on a client call on Tuesday. The wiki page is still there and still wrong, because nobody owns it and your system has no concept of one page replacing another.
Is that you?
the verdict is a default, not a law
- It is a wiki with a search box, and the search box returns documents and excerpts rather than sentences of its own
- Any AI answering happens in a DM to the person who asked, never in a shared channel
- The bot's Slack scopes are read-nothing and post-on-request — no history access, no ingestion of conversations
- Documents are files on disk with an owner and a verified-on date, and you have restored from the backup at least once
- A bot posts generated answers into channels, where the audience is a membership list nobody checked and the delete button is decorative
- You are mining Slack history into a searchable corpus without telling the people whose messages you are indexing
- Retrieval runs with more access than the person asking, so a summary can reveal a document whose link they will get a 403 from
- The workspace token in your environment file would, if leaked, hand somebody the company's entire chat history
If you build it anyway
the checklist, then the prompt that enforces it
- Answer in a thread on the asking user's message, or in a DM. Never post a generated answer as a top-level message in a shared channel, because that is the one action in this system you genuinely cannot take back.
- Filter the candidate set by the asking user's permissions before retrieval, and then check again against the audience of wherever the answer will be posted. Two different checks, both required.
- Request the narrowest Slack scopes that work and write down what each one grants. If ingesting history is a requirement, that decision belongs to whoever runs the company, not to you at 11pm.
- Give every page an owner and a verified-on date before you build any answering at all, and put a superseded-by field on it. A Q&A corpus without one accumulates contradictions and your retrieval will find every single one.
- Show the source and its verification date above the answer, never below, and make the bot say it does not know when the top matches are weak.
- Never ingest chat messages silently. If it happens, it happens with an announcement, an opt-out, a channel allowlist and a secret-scanner over everything you index.
- Down-rank pages with no owner or a stale verification date and surface them in a maintenance view. Tettra ships three reports for this; that is what the subscription is for.
- Publishing to the open web is per page, two steps, with a preview of the logged-out view and a deliberate choice about indexing. Default to noindex.
I am building an internal wiki whose main interface is a Slack bot: colleagues ask
questions in chat and it answers from our pages. People will act on those answers. Build
in this order, and push back when I ask for the bot first.
1. Before the bot exists, define page metadata: owner, created, updated, verified-on,
superseded-by. Refuse to build answering over documents that have none of these.
2. Enforce permissions server-side on every read. Retrieval filters candidates by the
asking user's access before anything reaches a model — never filter after generation.
3. Add a second check I will otherwise forget: before posting, evaluate the audience of the
destination. If it has members without access to a cited page, refuse and reply in a DM.
4. Default every answer to a threaded reply or a direct message. A top-level channel post
needs an explicit setting, and tell me that deleting one does not recall the Slack
notification previews it already sent.
5. Request the minimum Slack scopes. Enumerate what each grants and make me confirm anything
that reads history.
6. Ship search before answers: full-text with excerpts and links, on the database's own
index. Let me live with it for a fortnight.
7. Answers cite sources above the answer with the verified-on date visible, and say "I don't
know" when matches are weak. Never merge two contradictory pages into one paragraph.
8. If I ask to ingest Slack history, stop. It imports material nobody wrote for publication:
require a channel allowlist, scan everything indexed for secrets, and tell me this is an
announcement to the team rather than a deploy.
9. Verify Slack request signatures and acknowledge inside three seconds, doing the real work
asynchronously. Make repeated deliveries idempotent so the bot cannot double-post.
10. Log every question, answer, source used and destination. When somebody asks where the
wrong answer came from, that log is the only possible reply.
11. Nightly export of all pages to Markdown with metadata, into a directory I can browse.
12. Out of scope on purpose: realtime collaborative editing, external public sites and
connectors to other tools. Each is its own project with its own leak.
13. Finish by telling me that $8 a user with a ten-seat minimum is really $80 a month, and
what it buys: permission-aware retrieval and the reports that keep a corpus worth asking.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The answers are going to colleagues who will act on them. The real price is $80 a month, not $8 — the ten-seat minimum is the fine print here — and against that you are buying two things that take quarters rather than weekends: retrieval that respects permissions on both ends of the conversation, and the maintenance apparatus that keeps a Q&A corpus worth asking, which is verification dates, owners, and reports that tell you what has gone stale. A single-player notebook with a search box is still an excellent build. A bot that speaks for the company in a channel is a product, and the difference is that one of them can be wrong in front of everyone.
$8/mo is cheaper than your weekend.
The wiki half exits cleanly: a nightly export of every page to Markdown with front matter carrying owner, category, verified-on and superseded-by, attachments alongside with relative links. That directory imports into Outline, a git repository or a competitor on any afternoon. Two things do not travel and both need a decision. The retrieval index is derived — treat it as a cache, delete it, rebuild it, never migrate it. The Slack side is the real work: revoke the app's tokens, and keep a list of which channels you ingested and which pages you published externally, because unpublishing an external page is a request to a search engine rather than an action in your admin panel.
Actively developed open-source team wiki with real permissions, search and a Slack integration already built.
Open-source retrieval and chat platform with connectors and a Slack bot, which is the answering half done by people who thought about access control.
Questions
There are already three team wikis here. Why is this one scored higher?
Because of where the answer goes. Slite's failure is epistemic — a confident answer from a corpus with no freshness signal. Nuclino's is mechanical — last-write-wins quietly eating a paragraph. Slab's is ingestion — a search box that crawls other systems with admin eyes. Tettra's is egress: the answer leaves your application and appears in a chat channel under your bot's name, in front of an audience you did not choose, with a delete button that does not recall what was already delivered.
Is answering in a DM actually safer?
Considerably, and it is close to free. A DM has exactly one recipient, whose permissions you already checked to build the candidate set, and it gives the reader a moment to sanity-check the answer before repeating it. A channel post skips the reader entirely and goes straight to being quoted. If you build only one restriction into your own version, make it this one.
What is wrong with mining old Slack answers into the wiki?
Slack is not a knowledge base, it is an unedited transcript with different permissions and different expectations. People paste keys in it, discuss each other in it, and answer questions approximately because they know they are talking rather than publishing. Indexing that into a searchable corpus changes the purpose of the data, which is a conversation to have with the team and — in the EU — a lawful-basis question rather than a technical one.
- GDPR Art. 5 — principles relating to processing of personal data
- GDPR Art. 6 — lawfulness of processing (EU)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
A search box says "here are three pages". An answer box says "this is true". Only one of those can be wrong.
Last-write-wins is not an error you will ever see. It is a paragraph a colleague typed that quietly never existed.
The wiki is a weekend. The search box that reaches into Drive is a copy of the company, indexed with admin eyes.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice