Should I vibe code
Maintain a fast linked team knowledge base with collections and simple boards
Last-write-wins is not an error you will ever see. It is a paragraph a colleague typed that quietly never existed.
?
Their verdict, the Starter 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
A wiki is the most satisfying weekend project in software: documents, double-bracket links, a search box, a sidebar tree, done by Sunday afternoon and genuinely pleasant to use. Then a second person opens a page. Nuclino's entire personality is being fast with other people in the document at the same time, and concurrent editing is the one part of this that does not degrade politely — it does not throw an error, it silently keeps whichever save landed last and drops the paragraph your colleague typed while you were typing yours. Nobody notices for a week, and by the time they do, the version history you did not build is where the answer would have been. Publishing is the other trapdoor: every team wiki grows a "share this page" button within a month, and the page somebody shares is the onboarding checklist with the staging password in step four. Build it for yourself and it is lovely. Build it for a team and you have adopted real-time sync, permissions and search, permanently.
What actually breaks
not "if". the specific failures.
- Two people in one document, one of whom loses three paragraphs and finds out on Thursday
- Search, the first time the wiki holds 800 items and LIKE '%term%' stops being a search engine
- The public publish toggle, on the page that documents how to connect to staging
- Backlinks after a rename, where every reference to the old title silently points at nothing
- Edits made offline on a phone and replayed on reconnect over half an hour of other people's changes
- Image and file attachments, which are the reason the tidy Markdown-in-a-folder plan quietly stops being true
- Export, which nobody tests until the week the team wants to leave
- Version history, which exists in the schema and has never once been restored from
Is that you?
the verdict is a default, not a law
- It is yours alone, or read-only for everyone else, and the writes come from one keyboard
- Documents are files on disk in a format you can read without the app, and the app is a view over them
- There is a real version history — per-document, restorable, and you have restored from it once on purpose
- Nothing operational depends on it: the runbook that matters lives in the repository, not the wiki
- More than one person edits at once and you have not built either operational transforms or a CRDT, because the naive save is a silent data-loss machine
- It is where the team keeps the things it cannot lose — incident runbooks, contract terms, the list of who has which key
- You are adding public publishing without a per-page confirmation that shows exactly what becomes visible
- Colleagues will treat it as always-on infrastructure and you are the only person who can restart it
- You need search that works on the day it has ten thousand documents rather than the day you demoed it
If you build it anyway
the checklist, then the prompt that enforces it
- Decide the concurrency story before you write the editor. Either single-writer with a visible lock, or a real CRDT library — never a plain save that overwrites whatever it found.
- Version every save, keep the history for longer than you think, and put a restore button next to it. A wiki without history is a shared document with an undo stack of one.
- Store documents as files or as immutable revisions, so the recovery path does not depend on your schema being intact.
- Make publishing a per-page, two-step action that shows a preview of the public URL and lists every attachment it will expose.
- Use the database's full-text index from day one — Postgres tsvector or SQLite FTS5. Retrofitting search after the content exists is how the wiki becomes a folder.
- Rename must rewrite or redirect inbound links. Broken backlinks are how a knowledge base rots without anyone declaring it dead.
- Give it a nightly export to Markdown plus attachments, into a directory a human can browse. That export is your exit plan and your backup at the same time.
I am building a small team wiki: linked documents, a sidebar tree, search and
collaborative editing. Colleagues will trust it with things they cannot lose.
Follow these, and tell me when I am asking for something that quietly deletes
their work.
1. Answer the concurrency question before any UI. Recommend either single-writer
with a visible lock and presence indicator, or an established CRDT library.
Refuse a plain last-write-wins save, and say why: nobody ever sees an error,
a colleague simply loses what they typed.
2. Build revision history before the editor is pretty. Every save is an
immutable revision with author and timestamp, and the restore path exists.
3. Build export before import: a command that writes every document to Markdown
with its attachments into a dated folder, runnable from cron, tested today.
4. Use the database's native full-text search from the start, not a LIKE query I
will have to replace at 800 documents.
5. Publishing to a public URL is off by default, per document, two steps, with a
preview of exactly what a logged-out visitor sees — attachments included.
6. Renaming a document rewrites inbound links or leaves a redirect. Never let a
rename silently break references.
7. Attachments live outside the database with content-addressed names and are
included in the export.
8. Deletion is soft with a recoverable trash, and deleting a collection never
cascades silently to its documents.
9. Permissions are private, team or public, enforced server-side on every read.
No client-side hiding.
10. Out of scope on purpose: real-time cursors, comments and mobile apps. That is
where the remaining months go.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 a colleague other than you writes in it. At roughly $8 a seat, what you are buying is the two things that take months rather than a weekend: conflict-free simultaneous editing, and search that stays fast as the wiki grows. Both are invisible when they work, which is precisely why nobody budgets for them. A single-player Markdown notebook is still a great build; a shared one is a product.
$8/mo is cheaper than your weekend.
Make the nightly Markdown export the product's real output and everything else becomes optional. Documents as .md files in a folder tree that mirrors the sidebar, attachments beside them with relative links, one file per document, no database required to read any of it. Then the exit is a directory you can drop into Obsidian, a git repository or a competitor's importer on any given afternoon. What will not survive is the graph layer — backlinks, collections, boards — so keep a JSON sidecar per document with its links and tags, and accept that the shape of the wiki is the part you would have to rebuild.
Actively developed open-source team wiki with real-time collaborative editing, search and permissions — the closest thing to a reference implementation.
Open-source local-first workspace with documents and databases, useful if you want the offline story solved before the server one.
Questions
canivibecodeit says one sitting. Is that wrong?
No — the single-player version really is one sitting, and that is the version most people picture when they read the estimate. The gap between that and Nuclino is the word "team": simultaneous editing, presence, permissions and search-at-scale are not in the sitting, and each of them is the kind of work that is either done properly or done invisibly wrong.
Can I avoid the whole problem with a lock?
Yes, and it is an underrated answer. A visible "Dana is editing this" lock with a takeover button is a couple of hours of work, is trivially correct, and never loses a paragraph. It feels dated next to real-time cursors, and for a team of five it is the right trade almost every time.
Why is maintenance scored so high for something this simple?
Because a wiki is not a project you finish, it is one you adopt. Every document anyone writes increases the cost of it going away, and the requests arrive forever: search that understands plurals, an image that will not upload, a table that pastes badly from Google Docs, a document someone deleted last Tuesday. None of it is hard, and it never stops.
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.
A search box says "here are three pages". An answer box says "this is true". Only one of those can be wrong.
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