Should I vibe code
Internal knowledge base with search, integrations, and verification
The wiki is a weekend. The search box that reaches into Drive is a copy of the company, indexed with admin eyes.
?
Their verdict, the Startup 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 wiki is the easy half and you already suspect it: posts, topics, an editor, a full-text index, one pleasant weekend. Slab's pitch is the search box, which is sold as covering your own posts and the fifty-odd tools you connect to it, and that is where the shape of the build changes. Searching another system means mirroring it — holding a token for each person's Drive or Slack and keeping a copy of documents whose permissions live somewhere else entirely. The shortcut is the dangerous part precisely because it works: a service account with domain-wide read has a demo running by Saturday afternoon, and it indexes the company with an administrator's eyes. From then on your permissions are a snapshot taken at crawl time, and every result renders a two-hundred-character snippet of whatever the crawler could reach to whoever types the matching word. Slab's other idea, verification, is genuinely good and also a trap when homemade: an owner and a date on each post is a maintenance loop, but a badge that never expires is a lie with a tick next to it.
What actually breaks
not "if". the specific failures.
- The connectors, continuously and forever. Five APIs means five pagination models, five auth flows, five rate limits and five different opinions about what "changed since" means
- Permissions, which your index freezes at crawl time — the source system revokes access on Tuesday and your copy keeps answering questions about it on Friday
- The service-account shortcut, which is the version that actually ships, and which reads everything a domain administrator could read
- Snippets, because a search UI renders content, and a snippet is a leak with a character limit rather than an access control
- Verification badges, which decay silently: "verified" eight months ago on the refund policy reads to everyone as "current"
- Relevance across mixed sources, where a two-line Slack message and a forty-page handbook compete for the same top slot on the same score
- Deletions, which nobody propagates — the document is gone from Drive and present in your index, which is the one place it now exists
- Full re-crawls, which is how you meet the rate limits, and incremental sync, which is how you meet the documents that changed while you were not listening
- Attachments and images, which are what makes the tidy Markdown-in-a-folder plan quietly stop being true
The message arrives on a Friday afternoon, which is its own kind of bad. An engineer searched for "bonus policy" and got four results; the second was a spreadsheet called 2026 Comp Review, with a snippet showing three names and three numbers. He told you rather than his manager, which was generous. The file lives in a Drive folder shared with six people, none of them him, and the link in your result 403s when he clicks it — which is the detail that makes it worse, because your search page rendered the contents and then the source system correctly refused him the document. The cause is one line in the connector you wrote in March: it authenticates with a service account holding domain-wide read, because per-user OAuth was fiddly and it was only for search. Then comes the question you cannot answer. Who else searched a term matching that file in the last five months? You logged queries, and you logged how many results came back, but you never logged which documents they were, so the honest answer to the only question anybody actually cares about is that you have no idea.
Is that you?
the verdict is a default, not a law
- It is your own posts, your own index, and no connector to another system exists
- Each person's connected accounts are crawled with that person's own token, and results are scoped to whoever granted it
- Verification is a plainly rendered date and owner rather than a badge that says "verified" indefinitely
- You self-host Docmost or Outline and add the one thing you were missing
- The connector authenticates with a service account, an admin token or domain-wide delegation
- Search results render content the person asking could not open in the source system
- You cannot reconstruct, from a log, which documents a given search returned
- It has quietly become where the company 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
- Ship the wiki alone and live with it for a month before writing a single connector. Everything dangerous on this page arrives with the connectors, and they are also the part that looks like a Saturday.
- Never index with a service account. Per-user OAuth, per-user index scope, and a rule with a test behind it: a document enters someone's results only via a token that person granted.
- Re-check access against the source at query time rather than trusting the crawl. An ACL that changed since Tuesday is the ordinary case, not the exception.
- Log query, asker and returned document ids together. After an incident the only question is who saw what, and it cannot be reconstructed later.
- Treat snippets as content: render them only for documents the asker can open right now, and fall back to a title-only result rather than a preview you cannot justify.
- Propagate deletions and revocations on the same schedule as creations, and treat a 403 or 404 from the source as a removal rather than a transient error to retry forever.
- Make verification expire. A badge with a lifetime is a maintenance loop that surfaces stale documents; a permanent one is a lie with a tick next to it.
- Export nightly to Markdown with attachments into a browsable folder. That export is your backup and your exit plan at the same time.
I am building an internal knowledge base with search, integrations into our other tools, and
per-post verification. Colleagues will act on what it tells them. Build in this order and
refuse the shortcuts.
1. Build the wiki alone first: posts, topics, permissions, full-text search using the
database's native index. No connectors. I want to use it for a month before anything
crawls another system.
2. Enforce permissions server-side on every read, including search. Filter the candidate set
before ranking, never after.
3. Build export before anything else fun: a command that writes every post to Markdown with
attachments into a dated folder, runnable from cron and tested today.
4. Document metadata comes before the verification UI: owner, created, updated, verified-on,
verification lifetime, superseded-by.
5. Verification expires. When it lapses the badge changes state and the post appears in a
maintenance view. Never render an indefinite "verified" badge.
6. When connectors arrive, they use per-user OAuth only. Refuse to implement a service
account, an admin token or domain-wide delegation, even for a demo, and tell me why:
it indexes the whole company with an administrator's eyes and I cannot undo who saw what.
7. A document enters a user's result set only through a token that user granted. Write that
test before the first connector ships.
8. Re-check access against the source system at query time before rendering anything, and
degrade to a title-only result when the check fails or times out.
9. Log every search as query, asking user, and the ids of the documents returned. Retain it,
because the question after an incident is always who saw what.
10. Propagate deletions and permission changes on the same schedule as new documents. Treat
403 or 404 from the source as a removal, not a retry.
11. Store connector tokens encrypted, with a documented revocation path per provider, and a
command that lists every grant the app currently holds.
12. Out of scope unless I ask again: AI answers over the corpus, public sharing and real-time
collaborative editing. The first of those is a different entry with a different failure.
13. Finish by telling me what this costs per seat to buy, and what I am taking on instead.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
More than a handful of people write in it, or the moment anyone wants to search anything that is not in it. At $6.67 a seat annually — free below ten people — you are buying the two things that take quarters rather than weekends: connectors that respect each user's permissions in each source system, and a verification loop that keeps the corpus worth trusting. A single-team wiki you run yourself is a perfectly good build. A search box over the whole company's tools is an ongoing security posture, and it will be your name on it.
$6.67/mo is cheaper than your weekend.
The nightly Markdown export is the real artefact: posts as .md files in a tree that mirrors the sidebar, front matter carrying owner, tags, verified-on and superseded-by, attachments alongside with relative links. That folder drops into Docmost, Outline, Obsidian or a git repository on any afternoon. The part nobody plans for is the tokens. Your app holds OAuth grants across the company, and deleting the app does not revoke them — so keep a command that lists every live grant, and write the revocation checklist per provider while you still remember which scopes you asked for. The search index itself is derived; treat it as a cache, delete it, and never migrate it.
Actively developed open-source collaborative wiki with spaces, permissions, sharing and search.
Mature team knowledge base with realtime editing, Markdown compatibility and integrations, self-hostable and a good reference for the connector patterns.
Questions
Slite is demo only. Why is this one a band worse when they look like the same product?
The wiki halves genuinely are the same, and if you stop there so is the verdict. Slite's page is about the answer box — an LLM turning two contradictory documents into one confident paragraph. Slab's is about the index: to make one search box cover Drive, Slack and GitHub you have to hold credentials for other systems and keep a copy of their contents, and the copy's permissions are a snapshot of a moment that has passed. That is a security posture rather than a content problem, and it is the sort of thing that gets discovered by an engineer typing an innocent word.
Why is a read-only service account so bad? It cannot change anything.
Because read is the entire risk here. A domain-wide read grant means your crawler sees every document in the company, and from that point your index is the union of everything rather than a per-person view. Two things then go wrong on their own: your snippets show content to people the source system would refuse, and permission changes in the source never reach you, so a document locked down after a reorganisation stays searchable in your copy. Per-user OAuth is more work for exactly the reason it is safer — each index is bounded by what that person could already see.
Is the verification feature worth copying?
Yes, and it is the best idea in the product — with one condition. Verification has to expire. An owner plus a verified-on date plus a lifetime gives you a maintenance loop: things fall out of verification, appear in a queue, and somebody re-reads them. A permanent badge does the opposite, because it converts "someone read this in January" into "this is true", and the reader has no way to tell which of those they are looking at.
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.
A bot answering in a channel is not a search result. It is your company saying something, in front of twelve people.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice