Open DEV's front page on basically any day right now and you'll find an AI-generated component tool, an AI prompt that "generates production-ready code," or a chatbot bolted onto something that didn't have one last month. I'm not writing this to dunk on any of that — some of it is genuinely useful. But it's created a weird gravitational pull where every roadmap discussion eventually asks "should this have AI in it," even for problems that don't need it.
I went the opposite direction. Over the past year building a 70+ tool image/PDF platform, the actual hard engineering problems weren't "how do we add AI" — they were "how do we remove the server."
The Boring Problem Nobody's Hyping
Most image and PDF tools upload your file to a server, process it there, and send back a result. That's simple, well-understood, and it's also the thing I spent the most engineering effort trying to eliminate — not because servers are bad, but because for a huge category of tools (resize, compress, convert, crop), there's no actual reason a file needs to leave your device at all. Modern browsers can do this work themselves.
No AI model involved. Just Canvas API, a binary search over compression parameters, and a genuinely deterministic result — the same input always produces the same output, which turns out to matter a lot when someone's compressing an ID photo for a government form and needs to trust the tool didn't quietly do something unpredictable to it.
Where I Actually Considered AI, and Didn't Use It
To be fair to the other side of this — I did evaluate AI for a couple of features:
- Auto-crop/smart framing for passport photos — an AI model could theoretically detect face position and suggest a crop. I shipped a simpler geometric approach instead (detect the largest contiguous skin-tone region, center it) because it's instant, works offline, and — critically — fails predictably. When an AI auto-crop gets it wrong, it's not obvious why. When a rule-based approach gets it wrong, you can usually tell exactly what assumption broke.
- Smart compression suggestions ("this looks like it could go smaller without visible quality loss") — genuinely tempting to bolt an AI quality-assessment model onto this. Ended up with a much less exciting binary search against a target file size instead, because it's fast enough to run entirely client-side without an API call, and it doesn't need a network connection or ongoing inference cost per use.
Neither decision was "AI bad." Both were "this specific problem doesn't need a probabilistic model when a deterministic one solves it just as well, faster, and for free."
The Uncomfortable Question This Raises
If a meaningful chunk of "let's add AI" decisions in the current wave are driven by genuine capability gaps, that's great — ship it. But I suspect a real chunk of them are driven by something closer to FOMO than by an actual problem AI solves better than existing techniques. Deterministic, boring, well-understood approaches don't get a "Show HN" spike the way "I added AI to my todo app" does, even when the boring approach is objectively the better engineering call for that specific problem.
I don't think this makes AI overrated in general — some categories of problems (genuinely fuzzy classification, natural language understanding, generative tasks) are exactly where it belongs. I think it makes "did I choose AI because it's the right tool, or because it's the interesting one to talk about" a question worth actually asking before shipping, not after.
Where This Landed
The end result is ResizeHub — 70+ tools, no AI anywhere in the pipeline, no server ever touching a file, and it turns out "boring and deterministic" was the harder, more interesting engineering problem the whole time.
Genuinely curious where others have landed on this — have you shipped an AI feature and regretted it, or skipped one and been glad you did? Not looking for an anti-AI pile-on, actually curious about the cases that went either way.
Top comments (5)
Great perspective! I like how you challenge the trend of adding AI to everything. Sometimes simplifying the architecture and solving the real problem is more valuable than adding unnecessary complexity. Thanks for sharing your experience.
Thanks! I think that was the biggest lesson from building this. The hardest part wasn't avoiding AI—it was avoiding it just because everyone else was adding it. I kept asking one question: does this actually simplify the product, or does it add complexity? That filter ended up being much more useful than asking whether AI could solve the problem.
That's a really smart way to look at it. It's easy to add AI because it's trending, but focusing on whether it genuinely improves the user experience is what makes a product stand out.
This is such a grounded take. The line "did I choose AI because it's the right tool, or because it's the interesting one to talk about" — that's a question every team should ask before every sprint planning.
I see the same pattern in robotics. The flashy work is always "new AI model for X," but the real bottleneck underneath is often much more boring — like nobody agreeing on how to structure the data in the first place. The unglamorous plumbing that makes everything else possible.
Appreciate you writing this honestly and not just joining the hype train (or the anti-hype pile-on). Both are easy. Nuance is hard.
That's a great analogy. If the underlying data or architecture is messy, adding an AI model often just makes the failure more expensive. I kept running into the same thing while building ResizeHub—the real engineering work was in making deterministic, client-side algorithms reliable, not in adding another intelligent layer on top.
And I completely agree about nuance. It's much easier to say "AI changes everything" or "AI is overhyped" than to ask, "Is AI actually the right tool for this specific problem?" I think that's the more interesting engineering question.