How We Used Subtraction to Build a Truly Free AI Photo Editor

June 11, 2026

Hi, I'm on the engineering team behind EzMaker AI. We just launched a completely free AI image editing tool that does background removal, object erasing, quality enhancement, and 4K upscaling.

No sign-up required. Unlimited edits. All uploaded photos are permanently deleted within 24 hours.

You might be asking: "How is that sustainable?" "What's the tech stack?" "What went wrong?"

1. Problem-Driven: Why We Built This

Before writing a single line of code, we asked one question:

"What should the simplest AI photo editor look like?"

We looked at existing tools and found common problems:

Paywalls too early – 3–5 free edits, then subscribe
Login required – Can't even try without an account
Unclear privacy – No idea where photos go or who trains on them
Complex UX – Even "one-click" features are buried in menus

So we set three non-negotiable rules:

Permanently free, unlimited
No login of any kind
Photos auto-delete within 24 hours, never used for training

These three rules dictated every technical decision that followed.

2. Technical Architecture: From Prototype to Production

2.1 Image Processing Pipeline

Our core tasks include:

Background removal (semantic segmentation)
Object erasure (inpainting)
Upscaling (2x/4x/8x)
Quality enhancement (denoise, sharpen, deblur)

2.2 Backend Architecture

Key design decisions:

✅ No user accounts = no history

Each editing session is completely independent
No source or result images are saved
Download links expire in 1 hour
Temporary files are physically deleted within 24 hours

✅ Task queue + auto-scaling

Automatically spins up more GPU workers during spikes
Scales to zero when idle (cost control)
Queue timeout: 60 seconds, then one retry

✅ Cost control (critical)

We were terrified of: Free + unlimited = bankruptcy

Optimizations that worked:

Dynamic inference resolution based on image size (not everything needs 4K)
Smart caching – identical images uploaded twice hit cache
Model quantization (FP16 / INT8) – lower VRAM without noticeable quality loss
Batch optimization – merge requests during high concurrency

Result: Average cost per image is sustainable, and still dropping as we optimize.

3. Hard-Earned Lessons (So You Don't Have to Repeat Them)

Lesson 1: Ghosting artifacts in object erasure

Early LaMa outputs left blurry or repetitive textures. User feedback: "The object is gone, but now it looks like a smudge."

Fix:

Edge-guided inpainting
Local texture synthesis after erasure
For large-area erasures (>30% of image), prompt for more precise masking

Lesson 2: Hair and transparent objects in background removal

Standard matting models fail on curly hair, veils, glass, etc.

Fix:

Don't rely on a single model – add a matting refinement stage
Post-process low-confidence edge regions
Results now approach paid tools

Lesson 3: No login = no rate limiting = abuse

We were quickly hit by scripted batch uploads.

Fix:

Lightweight rate limiting (IP + fingerprint) – no user identity needed
HTTP 429 for abnormal frequency
No CAPTCHA – we don't punish real users

Current system stops abuse, and 99.9% of real users never hit a limit.

4. Practical Advice for Other Developers

If you're building something similar, here's what worked for us:

Technical advice

Ship the simplest model first. Replace it later. Don't over-optimize v1.
Every model needs a timeout and fallback. Some images will always fail.
Log success rates and latency per task. Let data drive model iteration.
Privacy isn't optional. If you can't afford compliance, don't store user data.

Non-technical advice

Free + unlimited is possible. Control costs. Don't over-engineer.
No login is not anti-business. It's a trust signal. Trust becomes word of mouth.
Test with 50–100 real users before launch. They will find unexpected usage patterns.