Should I vibe code
Capture text instantly, run reusable transformations, and file the result into local destinations
A capture app is judged on one number: milliseconds to first keystroke. Everything after that is a text field.
?
Their verdict, the Drafts Pro 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 capture loop — a box that is already focused, saves on every keystroke, and hands the text somewhere else — is a genuinely small program, and the homemade version has a real edge because you build the four destinations you actually use instead of a plugin system. Everything worth worrying about here lands on you and only you: a lost paragraph, a regex that ate the note, a sync conflict between your laptop and your phone. That is the definition of a build-it, right up until the moment it becomes the only copy of something.
What actually breaks
not "if". the specific failures.
- The first two characters, when the editor takes focus after the view renders instead of before it
- Autosave, which has to fire on every keystroke rather than on close — the entire premise is that you never press save
- A transformation that rewrites the draft in place with no undo stack, so one bad regex eats the note you were three seconds from sending
- Sync, the moment there is a second device: two offline edits to the same draft and no merge strategy beyond last-writer-wins
- The share sheet, the widget and the Watch complication, which are the actual reason anyone uses this on a phone and are OS plumbing rather than app code
Is that you?
the verdict is a default, not a law
- It writes plain text files into a folder you can open with anything else
- There is one device, or sync is somebody else’s problem — iCloud Drive, Syncthing, a git repo
- The destinations are the four you genuinely use, hard-coded, rather than an extension API
- It is going to be the only copy of anything you would miss
- Transformations overwrite the source text without keeping the original around
- Your second feature is your own sync protocol, which is where this stops being a notes project
If you build it anyway
the checklist, then the prompt that enforces it
- Write plain files into a visible folder. The exit plan is then `ls`, and it costs you nothing to have it.
- Persist on keystroke, not on blur or close. A capture tool that loses the last sentence is worse than no capture tool, because you stopped keeping the sentence anywhere else.
- Every action appends or creates a new draft; none replaces the source in place. Keep the original until the user deletes it explicitly.
- Do not write sync. Put the folder in a service that has already solved conflict resolution and spend the time on the editor instead.
- Measure cold start to focused cursor and treat anything over about 300ms as a bug. It is the only benchmark this category has.
I am building a quick-capture text app. Apply these constraints and push back if I ask you to break them. 1. Storage first, features second. Drafts are plain UTF-8 files in a folder I choose, one file per draft, with metadata in front matter. No opaque database as the source of truth — an index is fine, but it must be rebuildable from the files. 2. Persist on every keystroke with a debounce measured in tens of milliseconds, not on blur, not on close, not on app background. Show me the code path that survives a force-quit mid-sentence. 3. Focus the editor before the first paint, not after. Then write me a measurement of cold-start-to-first-keystroke and print it in the README. If it is over 300ms, tell me why before adding anything else. 4. Any transformation or action creates a new draft or appends to the current one. Nothing rewrites text in place. If I ask for in-place editing, refuse until there is an undo stack that survives a restart. 5. Do not build sync. If I ask for multi-device, tell me to put the folder in iCloud Drive, Dropbox, Syncthing or a git repo, and explain that offline edits on two devices is a distributed systems problem, not a feature. 6. Deletion is soft for 30 days into a trash folder on disk, and the trash is visible in the file system. 7. Hard-code the destinations I name. Do not design a plugin architecture, an action marketplace, or a scripting runtime. That is the part of the real product I am not rebuilding. 8. Deliberately out of scope: sharing, accounts, a server, collaboration, encryption at rest. Say so in the README so future me does not add them by accident. 9. Finally, remind me that the paid app costs under two dollars a month and owns the share sheet, the widget and the Watch — none of which is code I would enjoy writing twice.
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
If you are on Apple hardware and want the share sheet, the Watch complication, the widget and the Shortcuts actions, buy it. Twenty dollars a year is less than the afternoon you will lose to App Intents, and none of that work transfers to anything else you will ever build.
There barely is one, and that is the whole design goal: if drafts are text files with front matter in a folder you picked, moving to Obsidian, to Drafts itself, or to nothing at all is a copy operation you can do with Finder. The moment the text lives only in an app-shaped SQLite schema, you have built something you have to migrate out of rather than walk away from.
Open-source cross-platform notes with end-to-end encryption and sync; the closest working reference for the capture-and-sync half.
Markdown notes on disk with sync backends you do not have to write yourself — the storage model to copy.
Questions
If it is this easy, why does the paid app exist?
Because the easy part is the text box and the hard parts are all outside it: the share extension, the widget, the Watch app, the Shortcuts actions, and a decade of not losing anyone’s text. The editor is a weekend; the operating system integration is the product, and it is the least portable code you will ever write.
Is a data-loss risk tag not a bit much for a notes app?
It is the only structural risk here, so it is the one worth naming. Everything else about this build is contained — no strangers, no money, no regulator — but a capture tool earns its place by being where you put things before you have decided where they go, which means it routinely holds the only copy of a thought for a few hours. Files on disk make that survivable. An app-owned database does not.
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 fiction brainstorming tool is prompts with a nice wrapper. Make it yours.
Twenty-five reports, and most of them are counting things. The one you can’t write is the grammar engine.
A grammar checker you run locally never has to be trusted with what you wrote.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice