Should I vibe code
Photo and video filters, retouching, masks, and creator effects
Your filters are the asset. Polarr Next switches off in October; keep the recipes as files you own.
?
Their verdict, the Polarr Studio (monthly, in-app) 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
Polarr is a filter engine with an app around it, and the two halves have completely different answers. A colour pipeline — curves, HSL, tone, grain, a LUT — is a shader you can write in a weekend and it will look genuinely good, because that arithmetic has been settled for thirty years. Masks are where it stops being a weekend: a radial gradient is trivial, a subject mask that finds hair and holds still while you drag the slider is a model plus a lot of tuning, and RAW is a second project entirely. But the interesting thing about Polarr specifically is what has happened to it. Polarr Next, the browser RAW workflow, carries a notice that it disappears after 13 October 2026 and becomes Pixieset Photo Editor; the Polarr Pro app has not shipped an update since March 2025; the main app is still going. That is the whole argument for this build in one paragraph. The filters you have tuned over four years are the asset, the app that holds them is not, and somebody else is currently deciding what happens to the account they live in. Build the pipeline if you want. More importantly, get your recipes out as files.
What actually breaks
not "if". the specific failures.
- The originals, the first time an export path defaults to the input path and a batch run writes over four hundred RAW files
- The recipe, if a filter is stored as an opaque blob in a database rather than as a readable file next to the image — at which point your edits die with the app
- Subject and sky masks at the edges, where hair, glass and motion blur live and where the eye goes first
- Colour management, because a filter tuned in one working space and applied in another is not the same filter, and the difference only shows on someone else's screen
- RAW, which is demosaicing, camera-specific colour matrices and highlight recovery — none of which is a library call you finish in an afternoon
- Performance on a phone, where the pipeline that ran at sixty frames on your laptop GPU is a slideshow and a battery warning
- Model provenance, when the background or subject matting weights you fetched at runtime change licence or disappear
- Video, which is the same pipeline plus temporal consistency, and where a per-frame mask that flickers is instantly obvious
Is that you?
the verdict is a default, not a law
- It runs locally over your own library and never listens on a port
- Every edit is stored as a readable sidecar file beside the image, not as a row in a database
- Originals are never written over — output goes to a new path, always
- You are chasing a look rather than a product, and a fixed set of adjustments gets you there
- You needed the mask quality, because that is a model problem and it is the whole reason the paid apps exist
- The filter definitions only exist inside your app's storage
- You are doing this to move a filter library off Polarr and have not exported anything yet
- It has to run at interactive speed on a mid-range phone
If you build it anyway
the checklist, then the prompt that enforces it
- Store an edit as a small, readable file — JSON or a documented sidecar — next to the image. This is the single decision that decides whether your work outlives the app, and it is what darktable and Lightroom both get right.
- Never write over the source. Exports go to a new path and overwriting is an explicit flag, because a batch job that overwrites RAWs has no undo.
- Pin the working colour space and say what it is. Apply the pipeline in linear light, convert once on export, and keep the ICC profile through the whole chain.
- Version the filter format from v1. A look you tuned last year must still render the same after you add a slider, so either the parameters are versioned or the render changes under you.
- Preview on a downsampled proxy, render the full-resolution file only on export, and check they actually match — a preview that lies is worse than a slow one.
- Pin any matting or subject-detection weights locally with the licence recorded beside them, rather than fetching them at runtime from a host you do not control.
- Honour the EXIF orientation flag and strip GPS from anything you publish, which is the opposite of what a naive strip-everything call does.
- If you are migrating off Polarr, export the filters first and confirm you can re-render an old edit from the exported file. Do that before 13 October 2026, not after.
I want to build a photo filter and retouching app. The pipeline is the fun part
and the edit format is the part that matters. Build in this order and argue if
I try to skip step one.
1. Define the edit as a versioned, human-readable recipe file — an ordered list
of adjustments with named parameters — stored beside the image. Never as an
opaque blob in a database. Explain why before you write it.
2. Prove the round trip early: load a recipe, render it, save it, reload, and
assert the output is identical. That test is the reason the work survives.
3. Never modify the source file. All output goes to a new path; overwriting is
an explicit flag with a confirmation, because a batch over RAWs has no undo.
4. Fix the working colour space and apply the pipeline in linear light. Convert
once, on export, and carry the ICC profile through unchanged.
5. Build the deterministic adjustments first — exposure, curves, HSL, tone,
grain, LUT application. Get those exactly right before touching masks.
6. Then radial and gradient masks, which are analytic. Only then model-driven
subject or sky masks, and tell me honestly how they behave on hair, glass
and motion blur rather than showing me a portrait against a plain wall.
7. Pin any model weights locally and record the licence next to them. Do not
fetch weights at runtime from a URL I do not control.
8. Preview from a downsampled proxy, export from the original, and add a check
that the two agree within a tolerance you state.
9. Honour the EXIF orientation flag; strip GPS on export; keep copyright and
creator fields.
10. Keep it local. If I ask for cloud sync of other people's photos, stop and
tell me what that changes about storage, deletion and liability.
11. Out of scope unless I ask: video, RAW demosaicing, a filter marketplace,
accounts of any kind.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
Four dollars a month is close to nothing and the mask quality is what you are buying — that is genuinely hard, model-shaped work that a weekend does not reproduce. The caveat is unusually specific here: Polarr is mid-transition, with one app frozen since March 2025 and the browser product being folded into Pixieset in October 2026. Whichever you pick, treat the filter library as something to keep your own copy of.
$3.99/mo is cheaper than your weekend.
The exit plan is the architecture: if edits are recipe files beside the images, there is nothing to leave. Delete the app and the photographs are untouched, the looks are still readable text, and any future renderer can be pointed at them. This is also the migration plan for anyone currently on Polarr — export your filters to files while the export still exists, re-render one old edit from the exported file to prove it round-trips, and do it before the October 2026 date on the Polarr Next notice rather than after.
Open-source non-destructive RAW workflow whose whole edit history lives in a readable sidecar file, which is the design decision this entry is about.
Background and subject matting as a library, covering the mask half without training anything.
Embeddable browser editor if you want the canvas and UI solved and only need to write the filter pipeline.
Questions
Is Polarr still a going concern?
Partly, and the detail matters if you are deciding whether to stay. The main consumer app was updated in February 2026 and is clearly alive. The separate Polarr Pro app has shipped nothing since 24 March 2025. Polarr Next, the browser RAW workflow, displays a notice that it will not be available after 13 October 2026 and is transitioning to Pixieset Photo Editor. We are not guessing at what that means commercially — we are reading the dates off their own pages, and the dates say export your work.
Why is the filter format worth more attention than the filters?
Because a look is an hour of your taste and a renderer is a weekend of arithmetic. If the recipe is a readable file, you can rewrite the renderer whenever you like and every past edit still works. If it is a blob in an account, the renderer is fine and your four years of looks are hostage to a product decision you do not get a vote on. Every serious photo tool that has survived — darktable, Lightroom, Capture One — stores edits as data, not as pixels.
How hard are the masks, really?
Radial and linear masks are geometry and take an afternoon. Subject, sky and face masks are a segmentation model, and the quality difference between a demo and a product is entirely in the edges — hair, fur, glass, smoke, motion blur. Off-the-shelf matting models get you a convincing screenshot quickly and then plateau somewhere short of usable for actual retouching, which is exactly why this is DEMO ONLY and not SHIP 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.
Anyone can build the crop tool. Opening a .psd and handing it back unbroken is a decade of someone else's file format.
The AI half is one API call. So is the abuse: a stranger's photo, your GPU bill, your takedown obligation.
Every operation is a library call. The product is that it runs in a browser tab on a 40MP file without dying.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice