Should I vibe code
Create a clean team wiki with documents, collections, search, and lightweight answers
A search box says "here are three pages". An answer box says "this is true". Only one of those can be wrong.
?
Their verdict, the Basic 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
The documents are the easy half and you already know that. What Slite actually sells is the claim that the answer you get back is current — doc owners, verification dates, a knowledge panel that surfaces what has gone stale, and an ask-a-question box that cites the page it drew from. Rebuild that and you will have the box within a weekend, because retrieval over your own Markdown is a solved afternoon, and it will confidently quote the 2023 refund policy to whoever asks, because nothing in your corpus knows which of two contradictory pages is the live one. Freshness is a workflow, not an index. The second trap is smaller and sharper: every team wiki grows a share button, and a page you publish to the open web with a sitemap and a custom domain is a page Google keeps a copy of. Unpublishing is a form you fill in later, at someone else's pace.
What actually breaks
not "if". the specific failures.
- The answer box, which has no notion of authority. Two documents disagree, retrieval picks the one with better keyword overlap, and a colleague acts on a policy that was replaced eighteen months ago
- Citations, once they start looking convincing. A wrong answer with a plausible source link is trusted more than a wrong answer without one
- Public publishing. A page with an indexable URL and a sitemap gets crawled within hours; taking it down is your afternoon, taking it out of the index is Google's
- Permissions on retrieval, where the answer engine cheerfully summarises a document the person asking is not allowed to open — the citation link 403s and the summary already told them
- Staleness, structurally: nothing marks a document as verified, nobody owns it, and the wiki degrades into an archive nobody trusts and nobody deletes
- Search once the wiki passes a few hundred documents and a LIKE query stops resembling a search engine
- Attachments, which are the reason the tidy Markdown-in-a-folder plan quietly stops being true
Is that you?
the verdict is a default, not a law
- It is a personal knowledge base, or read-only for everyone but you
- The answer box is off and search returns documents with excerpts, so the reader does the judging
- Documents are files on disk you can read without the app, backed up on a schedule you have actually restored from
- Nothing operational depends on it — the runbook that matters lives in the repository
- An LLM answers questions for colleagues from documents with no owner, no verified-on date and no way to mark one page as superseding another
- Retrieval runs with more access than the person asking, which is how a summary leaks a document the permissions were supposed to protect
- Public sharing exists without a preview of exactly what a logged-out visitor sees, and without a robots directive you chose deliberately
- It has become the place the team keeps things it cannot lose, and you are the only person who can restart it
If you build it anyway
the checklist, then the prompt that enforces it
- Give every document an owner and a verified-on date before you build the answer box. Retrieval without freshness metadata is a confident narrator with no editor.
- Filter by permission before retrieval, not after generation. The check has to run on the candidate set, because you cannot un-summarise a document once it is in the context window.
- Show excerpts and links by default; make generated answers an opt-in that always renders its sources above the answer, not below it.
- Publishing is per-document, two steps, with a preview of the logged-out view and an explicit choice about indexing. Default to noindex and make the reader turn it off.
- Keep a superseded-by field. A wiki without one accumulates contradictions and every retrieval system you bolt on will find them.
- Use the database's native full-text index from day one — Postgres tsvector or SQLite FTS5. Retrofitting search after the content exists is how a knowledge base becomes a folder.
- Nightly export to Markdown plus attachments into a browsable directory. That export is your backup and your exit plan at once.
I am building a team wiki with search and an AI answer box over the documents.
Colleagues will act on what it tells them. Build in this order and refuse the
shortcuts.
1. Before the editor, define document metadata: owner, created, updated,
verified-on, superseded-by. The answer layer is only as good as this.
2. Permissions are enforced server-side on every read, and retrieval filters the
candidate set by the asking user's access before anything reaches a model.
Never filter after generation — a summary of a document they cannot open is
still a leak.
3. Build export before import: a command that writes every document to Markdown
with attachments into a dated folder, runnable from cron, tested today.
4. Search first, answers second. Ship full-text search with excerpts using the
database's native index, and let me live with it for a while.
5. When the answer box exists, it cites every source above the answer with the
verified-on date shown, and says "I don't know" when the top matches are
weak. Never merge two contradictory documents into one confident paragraph.
6. Down-rank documents with no owner or a stale verification date, and surface
them in a maintenance view instead of quietly using them.
7. Public sharing is off by default, per document, two steps, with a preview of
the logged-out page and its attachments. Emit noindex unless I explicitly
ask for indexing, and warn me that an indexed page outlives the unpublish.
8. Deletion is soft with recoverable trash, and deleting a collection never
cascades silently to the documents inside it.
9. Attachments live outside the database, content-addressed, and are included in
the export. Renaming a document rewrites inbound links or leaves a redirect.
10. Out of scope on purpose: real-time collaborative editing, comments and
connectors to other tools. Those are the paid product, and the first of them
is a research problem rather than a sprint.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 moment more than one person writes in it, and especially the moment anyone asks it a question instead of reading it. At $10 a seat you are buying the two boring things that take quarters rather than weekends: retrieval that respects permissions, and a maintenance loop — owners, verification, stale-doc surfacing — that keeps the corpus worth asking. A single-player Markdown notebook is still a lovely build. A shared one that answers questions is a product.
$10/mo is cheaper than your weekend.
Make the nightly Markdown export the real output and everything else is optional. Documents as .md files in a tree that mirrors the sidebar, front matter carrying owner, tags and verified-on, attachments alongside with relative links. That directory drops into Obsidian, a git repository or a competitor's importer on any afternoon. Two things will not survive and are worth deciding about early: the answer index, which you should treat as a derived cache and rebuild rather than migrate, and any page you published to a public URL — write down which ones those were, because unpublishing them is a separate job you will otherwise forget.
Actively developed open-source collaborative wiki with spaces, permissions, sharing and search.
Open-source local-first workspace with documents and databases, useful if you want the offline story solved before the server one.
Questions
How is this different from the Nuclino verdict?
Nuclino's failure mode is mechanical — two people typing and a save that silently keeps the last one. Slite's is epistemic. Its pitch is that the wiki answers you, and an answer engine over documents with no owner and no verification date is a machine for laundering stale information into confident prose. Same category, different thing that bites you.
Isn't retrieval over my own docs basically solved now?
The retrieval is. The corpus is not. Embedding a folder and getting relevant chunks back is genuinely an afternoon; deciding which of two contradictory onboarding pages is the live one is a workflow with humans in it. That is the part that does not come out of a library, and it is the part that determines whether the answers are worth anything.
Why is publishing scored as harder to reverse than deleting a document?
Because deleting is within your system and unpublishing is not. Once a page has been fetched by a crawler it exists in an index, a cache and possibly an archive site, none of which you control. Removing it is a request you file and wait on. That is why the default should be noindex and the toggle should show you the logged-out page before you flip it.
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.
Beautiful documents are a typography problem, and typography does not respond to prompting.
Last-write-wins is not an error you will ever see. It is a paragraph a colleague typed that quietly never existed.
Tagged Markdown notes in a folder. The format outlives every app that has ever held it.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice