Should I vibe code
Organize interview notes, code excerpts, and synthesize themes into findings
The tagging UI is a weekend. A taxonomy that survives three researchers and two years is the whole product.
?
Their verdict, the Professional 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
Everything visible in a research repository is easy. Documents, highlights, tags, a filter sidebar, a report view — an agent will produce a convincing one in an afternoon and it will feel like you have solved something. You have not, because the value of a research repository is not created on the day you put a note in. It is created eighteen months later when a designer types a half-remembered phrase from an interview she was not present for and the right excerpt comes back. That depends on three things nobody demos: retrieval that works when you have forgotten the tag, a taxonomy that has not silently forked into `pricing`, `price` and `cost` across three researchers, and provenance that connects a claim in a slide back to the sentence a real person said. Build the v0 to find out what your team actually tags — that is a genuinely useful weekend. Just be honest that the thing you are storing is recordings of identifiable people who consented to a study rather than to a permanent searchable corpus, and that the deletion promise on the consent form is now a feature you owe them.
What actually breaks
not "if". the specific failures.
- Retrieval, which is the entire product. Keyword search over transcripts fails exactly when you need it, because you remember what the participant meant and not the words she used
- The taxonomy, which forks the moment a second researcher joins — three near-identical tags for the same theme, no merge tool, and a year of excerpts split across them
- Provenance, once a finding is quoted in a deck. A claim that cannot be traced to a timestamped sentence in a specific session is an opinion with a chart next to it
- Consent scope, because participants agreed to a study with a purpose and a retention period, and a permanent searchable repository is neither
- The deletion request, which has to reach the transcript, the excerpts, the tags, any embeddings you generated and the exported report — and typically reaches only the first
- Synthesis features, the moment they mean shipping a participant's verbatim transcript to a model provider that was not named on the consent form
- Transcript quality, since diarisation confuses two similar voices and an excerpt attributed to the wrong speaker is worse than a missing one
- File storage, which is where recordings and video actually live, and which grows quietly until it is both the biggest cost and the least backed-up part of the system
- Institutional memory, because the value is the accumulated history — and a homemade repository that dies takes two years of tagged excerpts with it
Is that you?
the verdict is a default, not a law
- It is your own notes from your own interviews, and you are the only person who will ever search them
- The transcripts are anonymised at intake, with names and employers stripped before anything is stored
- You are deliberately building a throwaway to learn what your team actually wants to tag before committing to a tool
- Everything is exportable as plain files from day one, so the repository dying costs you a workflow rather than a corpus
- Participants signed a consent form with a retention period or a stated purpose, and you cannot honour either from your data model
- Recordings of identifiable people would be stored somewhere you have not thought about access control for
- You are sending transcripts to a model provider and the consent form does not mention it
- More than one person will tag, and there is no merge, rename or controlled-vocabulary story
- The repository is meant to be the durable record and there is no export, no backup and no migration path
If you build it anyway
the checklist, then the prompt that enforces it
- Anonymise at intake, not at export. Strip names, employers and contact details on the way in and keep the mapping somewhere separate, so the corpus itself is not a directory of identifiable people.
- Write the deletion path before the search box: one function that removes a participant from transcripts, excerpts, tags, embeddings, generated summaries and exports, with a test asserting nothing survives.
- Attach the consent terms to the session record — purpose, retention date, whether third-party processing was disclosed — and let the app refuse operations the consent does not cover.
- Make tags a controlled vocabulary from day one, with rename and merge as first-class operations. Free-text tagging across three people produces a taxonomy that cannot be fixed retroactively.
- Keep provenance immutable: every excerpt carries session ID, speaker and timestamp, and every generated finding carries the list of excerpt IDs it came from. A synthesis you cannot trace is not a finding.
- Store source files as plain files in a bucket with a manifest, not as blobs in a database. It makes the export real and the backup boring.
- Add search that survives forgotten vocabulary — full-text plus vector, with the raw text retained so you can re-index when you change your mind about the embedding model.
- Before sending anything to a model provider, check the consent form. If it does not disclose third-party processing, redact first or do not send.
I am building a user-research repository: interview transcripts, tagged excerpts,
themes and reports. The participants are real identifiable people who signed a
consent form. Build the obligations before the features.
1. Model consent as data on every session: purpose, retention date, whether
recording was permitted, whether third-party or AI processing was disclosed.
Nothing gets imported without it.
2. Anonymise on the way in. Strip participant names, employers and contact details
at intake and keep the mapping in a separate store with its own access path. Do
not defer this to export time.
3. Write the erasure function before the search UI: remove one participant from
transcripts, excerpts, tags, embeddings, summaries, cached reports and file
storage, with a test asserting nothing survives. Retention expiry calls it too.
4. Make tags a controlled vocabulary from the first commit, with rename and merge as
real operations and a warning on near-duplicates. Free-text tags across several
researchers cannot be fixed later.
5. Every excerpt stores session ID, speaker and timestamp, immutably, and every
generated theme stores the excerpt IDs behind it. Refuse to produce a summary
that cannot be traced back to specific excerpts.
6. Source files live in object storage with a manifest and a documented export, not
as blobs in the database. Prove the export works before adding features.
7. Search: full-text first, vector second, raw text always retained so the index can
be rebuilt. The embedding model must not be a one-way door.
8. Before any call to a model provider, check the session's consent record and
refuse if third-party processing was not disclosed. Say so rather than silently
skipping the session.
9. Access control is per project, and anything shared outside the team is an
expiring link — never a public URL that happens to be long.
10. Out of scope until I ask: collaborative editing, video playback, dashboards,
surveys. If this is meant to be a team's durable record, tell me Aurelius is $49
a month for unlimited users and that losing two years of excerpts costs more.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
When the repository stops being yours and starts being the team's. $49 a month is unusual in this category for being flat rather than per-seat, so the usual "it costs more as we grow" argument does not apply, and what you are buying is the unglamorous half: search that works when you have forgotten the tag, a taxonomy with merge and rename, provenance from a slide back to a timestamp, and a vendor whose backup story is not a cron job you wrote. Build the throwaway first if you like — it is the cheapest way to learn what your team actually tags — then buy the thing that has to still be there in 2029.
$49/mo is cheaper than your weekend.
Plan the exit as a file format, not as a migration. Keep source documents and recordings as plain files in a bucket with a manifest, and keep excerpts, tags and findings as a flat export — one row per excerpt with session ID, speaker, timestamp, text and tags — regenerated on a schedule so it is never stale. That single file is what makes the repository portable into Aurelius, Dovetail or a spreadsheet, and it is also what survives if the app stops running. On the way out, honour the consent terms rather than just copying everything across: anything past its stated retention date should be deleted, not migrated, and that is far easier to do while you still have a working tool than during a handover.
Free and open-source qualitative coding tool that imports documents, highlights and tags excerpts, and exports everything — the closest honest match, and a good look at what the core data model needs to be.
Actively developed desktop qualitative analysis application covering text, image and audio-video coding with reports and exports.
Questions
Why is this DEMO ONLY rather than SHIP IT? Nothing dangerous happens.
Because the demo and the product are separated by two years rather than by a feature list. The tagging interface is genuinely easy, and it is also the part that stops mattering the moment there is more content than one person can hold in their head. The gap is retrieval, taxonomy hygiene and provenance, none of which look broken on day one and all of which are the reason the paid tools exist.
Is the personal-data angle overstated for internal research?
Consider what an interview recording actually is: an identifiable person, on video, discussing their job, their employer's plans and sometimes their health or finances, under a consent form that promised a purpose and a retention period. That is a higher grade of personal data than most product databases hold, stored in the system with the loosest access control in the company, and usually with no deletion path at all.
Can I just point an LLM at the transcripts and skip the tagging?
For your own notes, yes, and it is a good use of a weekend. For a team repository, two things bite. Synthesis without provenance produces claims that cannot be traced to a sentence a real person said, which is exactly the claim a stakeholder will challenge. And sending verbatim transcripts to a model provider is third-party processing that your participants' consent form probably does not mention. Keep the excerpt IDs behind every generated theme, and check the consent record before the API call.
What is the one thing to get right if I build it anyway?
Export. Every excerpt as a row with session ID, speaker, timestamp, text and tags, regenerated on a schedule, plus the source files as plain files with a manifest. It makes the repository portable, makes the backup real, and turns the day you abandon your own tool from a data-loss event into an afternoon of importing a CSV.
- GDPR Art. 5 — principles relating to processing of personal data
- GDPR Art. 32 — security of processing
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 public feedback board is a public spam target with a voting mechanism attached.
An open post box on your own domain is a spam farm with your favicon on it.
A public roadmap is a promise with a timestamp. The board takes an afternoon; the year of keeping it honest does not.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice