Should I vibe code
Photo editor, collage maker, and template-based graphic design
Every operation is a library call. The product is that it runs in a browser tab on a 40MP file without dying.
?
Their verdict, the BeFunky Plus 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
Split this in two and the answer falls out. The operations — crop, resize, filters, background removal, upscaling, cartoonising — are library calls and open weights, and a script that walks a folder and applies them is a genuinely good afternoon. Ship that. What you cannot rebuild is the thing you were actually using: a non-destructive editor that stays responsive on a 40-megapixel file inside a browser tab, plus a template and font library somebody licensed. And the moment you turn your afternoon script into a web app so it is convenient, you have built a public endpoint that accepts arbitrary files from strangers and hands them to an image decoder — which is one of the oldest reliable paths to running someone else's code on your server. The verdict is DEMO ONLY for the product. The CLI is a SHIP IT hiding inside it.
What actually breaks
not "if". the specific failures.
- The upload endpoint, if you host it: an untrusted file handed to an image decoder is the classic route to arbitrary code execution, and ImageMagick and libwebp both have the CVEs to prove it
- Browser memory, the first time somebody opens a 40-megapixel photo and you loaded the whole thing into a canvas at full resolution
- Non-destructive editing, which is what makes an editor an editor — an undo stack over pixel operations is not the same thing as a list of edits you can reorder and re-render
- Edges: hair, glass, smoke and motion blur, where every matting model is weakest and exactly where the eye goes first
- Colour, quietly — strip an ICC profile on the way in and every export comes back subtly wrong on somebody else's screen
- EXIF, in both directions: keep it and you are republishing the GPS coordinates of where the photo was taken, strip it and you have thrown away the orientation flag and half the images are sideways
- The template and font library, which is most of what people open BeFunky for and is a licensing exercise rather than a coding one
- Model archaeology, because the background remover that works today is a weights file on somebody's host with a licence that can change
Is that you?
the verdict is a default, not a law
- It runs on your own machine over your own folders and never listens on a port
- You are doing one repeatable operation in bulk rather than editing interactively
- Originals are never overwritten — output goes somewhere new, always
- The fonts and templates you use are ones you can point at a licence for
- Anyone else can upload a file to it
- It is processing photos of people whose EXIF location data you have not thought about
- You are about to hand a client artwork built on fonts you found on a download site
- You needed the interactive editor, because that is the part you are not going to finish
If you build it anyway
the checklist, then the prompt that enforces it
- Keep it a CLI or a local app for as long as you possibly can. Every serious risk in this entry appears the moment it accepts uploads from someone else.
- If it must accept uploads: validate by decoding in a sandboxed worker or container, not by trusting the extension or the MIME type, and cap dimensions and pixel count before any decode. Decompression bombs are a one-line denial of service.
- Never write over the input. Output to a new path, and make overwriting an explicit flag you have to type.
- Store edits as a list of operations rather than baking them into pixels, so re-rendering at a different size or undoing step three is possible at all.
- Decide EXIF policy explicitly and write it in the README: honour the orientation flag, strip GPS from anything you publish, and say which you did.
- Preserve or convert ICC profiles deliberately. Silently dropping them is the difference between a photo that looks right and one that looks washed out on every other device.
- Work on a downsampled proxy for the interactive view and apply the operations to the full-resolution file only on export.
- Pin model weights locally with their licence recorded next to them, because 'the same script produces the same result next year' is not otherwise guaranteed.
I want to rebuild a browser photo editor. Constrain me. Ordered, and argue back
if I ask for the web version before the safe parts exist.
1. Build a local CLI first: input folder, output folder, a named pipeline of
operations. No server, no port, no upload. Prove the operations work before
anything is exposed.
2. Never write over the source file. Output always goes to a new path, and
overwrite is an explicit flag with a confirmation.
3. Represent an edit as an ordered list of operations plus parameters, stored as
JSON beside the output. Re-rendering must be reproducible from that file.
4. Handle EXIF deliberately: honour the orientation tag, and strip GPS and
camera-serial fields from anything destined to be shared. Print what you
stripped.
5. Preserve ICC colour profiles, or convert to sRGB explicitly and say so. Do
not silently discard them.
6. If I ask for a web UI, stop and tell me that an upload endpoint feeding an
image decoder is a remote-code-execution surface, then: decode in a
sandboxed worker or container, enforce a pixel-count and byte-size cap before
decoding, sniff the real format rather than trusting the extension or
filename, and serve outputs from a domain that is not the app's.
7. Rate-limit and authenticate uploads from the first commit. There is no
version of a public, unauthenticated image processor that stays yours.
8. For interactive editing, operate on a downsampled proxy and apply the
pipeline to the full-resolution original only on export. Tell me the memory
ceiling you assumed.
9. Pin any model weights locally and record their licence in the repo. Do not
fetch weights at runtime from a URL you do not control.
10. Do not ship a template or font library. If I ask for one, say plainly that
embedding a typeface is a licensing question, not a file-copying one.
11. Out of scope: layers, collaborative editing, cloud storage of other people's
photos, batch AI credits.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 want the editor rather than the operations. $14.99 a month buys a canvas that stays responsive on large files, a template and font library that has been licensed, and — for the Pro tier's batch tools — somebody else's GPU bill. The subscription is a bad deal for 'remove the background from 500 product shots', which is a script, and a good one for 'make a poster by Thursday', which is not.
$14.99/mo is cheaper than your weekend.
There is very little to escape from, which is the nicest thing about this category: the outputs are files, the inputs are files, and if you delete the project tomorrow your photos are exactly where they were. Keep the edit lists as JSON next to the images and you can even re-render later with different code. The only lock-in you can create is overwriting originals, so don't.
Background removal as a command-line tool and library, which is one of BeFunky's headline features.
Open-source in-browser image editor you can embed rather than writing the canvas layer.
Open-source design tool covering the graphic-design half rather than the photo half.
Questions
Clipdrop is SHIP IT and this is DEMO ONLY. Why?
Clipdrop is a set of operations, and operations are open models you run locally over your own files. BeFunky is an editor: an interactive canvas, a template library and a font library, all delivered in a browser tab. The operations transfer to your weekend. The editor does not, and the assets are somebody's licensing department.
What is the actual security concern with a photo editor?
Only the hosted version has one, and it is specific: accepting a file from a stranger and passing it to an image decoder has been a reliable path to running attacker code since ImageMagick's ImageTragick and again with libwebp. Add decompression bombs, which take a 2KB upload and ask for 30GB of RAM. A local CLI over your own files has none of this.
Do I really need to think about EXIF?
Yes, and in both directions. Publishing a photo with its GPS tags intact discloses where it was taken, which for pictures of homes and children is a real problem. Stripping EXIF wholesale throws away the orientation flag, which is why half your exports come out rotated. Pick a policy, write it down, and test 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.
Background removal is a model someone else trained and gave away. Point it at a folder and stop paying per image.
Background removal is a model you can download and a batch loop you can write.
The editor is hard, the template library is harder, and the font licensing is a legal department.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice