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 (0)