I really want to see comments on this article.
I Built a Batch Image Processor with Zero Backend — Here's How
25 Comments
Great write-up and an extremely useful tool, Maxim! 👏
The privacy aspect and full client-side processing is a huge selling point. Preparing client assets — like generating web-ready WebP galleries, batch resizing, or formatting logos into multiple aspect ratios — usually turns into a massive time sink on web projects.
Most cloud tools hit you with aggressive paywalls or NDA/privacy risks, while writing custom scripts for every small task can be overkill when you just need a clean, visual, one-click solution.
Doing all of this zero-backend with live previews right in the browser is brilliant UX. Next time a client hits me with a mountain of photos and logos to process, I’m definitely testing Image Pipeline! Congrats on shipping this! 🚀
@[kate8382] Thanks Kate! 🙏
You nailed exactly the workflow I built this for — "mountain of photos and logos to process" hits too close to home. The NDA/privacy angle is real: I stopped counting how many times I had to explain to clients why their unreleased book covers were sitting on some server in California.
Let me know how it goes when you test it! If you hit any friction or need a node that doesn't exist yet, drop a note — I ship fast.
— Max
Please log in to add a comment.
Really impressive build! What stood out to me most is how the technical choices directly solve real user problems. Keeping image processing entirely client-side makes the privacy promise genuinely valuable, especially for designers working with confidential client assets.
I also love how you used real user feedback to shape the product instead of trying to build everything upfront. The combination of visual pipelines, live previews, and a simple one-time pricing model makes this feel thoughtfully designed rather than just technically impressive.
“Privacy is a feature, not a footnote” is definitely the takeaway here. Great work! 👏
@[amitasharmaa] Thanks Amitasha! 🙏
"Privacy is a feature, not a footnote" — you summed it up better than I did in the article. That line is going on the landing page.
The one-time pricing was a selfish choice: as a user, I hate subscriptions. As a founder, I hate chasing MRR. One-time felt honest for a tool that doesn't have recurring server costs.
Would love to hear what you think if you give it a spin — especially if you hit a workflow that breaks the pipeline. Those edge cases teach me the most.
— Max
Please log in to add a comment.
@[SpaceShaman] Thanks! I've thought about it. The tricky part is the payment verification code — that can't be open sourced. But the image processing engine (Canvas API, color matrices, nodes) is pure TypeScript with zero dependencies — I could extract that into a separate library. I'll ping you here when I get to it. If you spot something interesting — PRs welcome, no pressure :)
@[Maxim Mitenkov] If you mean actual secrets or credentials, those probably shouldn’t be hardcoded even in a private repository. Environment variables or a dedicated secrets-management solution are usually a much better approach, so sensitive values never end up in the codebase in the first place ;)
Please log in to add a comment.
@[Maxim Mitenkov] Solid answer for that scope. Only thing I'd try: sample the same matrix across a wider gamut (skin tones, saturated brand colors) before locking it, since hand-tuning on 20 images can hide edge-case shifts that show up on client work later. If you ever wanted it data-driven, a tiny supervised set of mood-labeled images mapped to a target matrix via least squares would get you consistency without full ML overhead. But honestly, for a shipped product, looks right, ship it beats over-engineering a filter nobody complained about.
Please log in to add a comment.
This is a really nice example of solving a real problem without adding unnecessary infrastructure.
The “images never leave the device” part is especially strong. Privacy isn’t just a checkbox here, it actually changes why someone would choose the tool.
Also liked the “ship, get feedback, improve” approach. Much better than spending months building 40 nodes nobody asked for.
@[buildbasekit] Thanks! "Privacy isn't just a checkbox" — I'm stealing that line for the landing page. And you're absolutely right about 40 nodes nobody asked for. The first user gave me 2 stars and a list of complaints. Five days later I shipped the fixes and got 5 stars. That's the only roadmap I need.
Please log in to add a comment.
Canvas only is the right call for this workload. Once you are already inside getImageData you are holding the exact same RGBA grid a vision model consumes, so the natural next node is a classifier that routes or skips images by content instead of by file size.
Two things that bite when you add that step. Canvas toBlob quality is not comparable across browsers, so a fixed 0.8 produces different file sizes in Safari and Chrome and your compression node stops being deterministic. And getImageData over a large batch will pin the main thread unless each node yields between images, which matters more on the old devices you are deliberately supporting.
For anyone curious what that pixel grid actually turns into inside a model, how computer vision works walks through the whole path from raw pixels to detections.
@[AIAppsAPI] Solid points. toBlob inconsistency (Safari vs Chrome) is on my list — adaptive re-compression might be the fix. Main thread blocking: sequential processing with callbacks helps, but true yielding or Web Worker pipeline is the real solution. The AI classifier node (MobileNet-level, client-side) is a fascinating direction — route by content, not by metadata. Will check the CV link. Thanks!
Please log in to add a comment.
Please log in to comment on this post.
More Posts
- © 2026 Coder Legion
- Feedback / Bug
- Privacy
- About Us
- Contacts
- You Tube
- Tiktok
- Premium Subscription
- Terms of Service
- Early Builders
Image Pipeline is a node-based batch image processor running 100% in the browser via Canvas API. No server uploads, no signup, no subscriptions. Free tier + one-time Pro/Lifetime.
Tech stack: React 19, TypeScript, Vite, Tailwind CSS, Zustand, React Flow. 16 Vercel Edge Functions. Zero backend for image processing.
When not coding, I illustrate book covers and run vimark.art. Show less
More From Maxim Mitenkov
Related Jobs
- Staff Backend Engineer, AMERGitLab · Full time · Canada
- Intermediate Backend Engineer, AMERGitLab · Full time · Canada
- Backend DeveloperRazor Talent · Full time · Alexandria, VA
Commenters (This Week)
Contribute meaningful comments to climb the leaderboard and earn badges!