1
3 Comments

The best feature in my AI product might be the one that doesn’t call an AI model

When I started building AIMakeTattoo, I assumed the AI image generator would naturally become the center of the product.

After all, tattoo ideas are visual. Give someone a prompt, generate a design, iterate from there.

But the longer I’ve worked on it, the more I’ve started to think that some of the most useful parts of an AI product may be the parts that don’t need AI at all.

A good example is Roman numeral tattoos.

If someone wants to turn a date into Roman numerals, that is not a creative problem. There is a correct conversion and there are incorrect conversions.

Using a generative model for that would actually make the product worse.

So I built a dedicated Roman Numeral Tattoo Generator instead.

The conversion itself is deterministic. The interesting decisions come afterward: separator style, spacing, year-only vs. full date, typography, size, and whether the result will still be readable as a tattoo.

That distinction changed how I started thinking about the rest of the product.

There are roughly three kinds of problems I keep running into:

  • Exact problems — conversion, text, dimensions, arithmetic. These should usually be deterministic.
  • Planning problems — size, placement, cost ranges, readability. These benefit from structured inputs and transparent rules.
  • Open-ended visual problems — composition, style exploration, combining several ideas. This is where generative AI becomes genuinely useful.

The mistake would be forcing all three through the same AI-shaped hole.

Tattoo pricing is another example.

Someone asking “how much might this tattoo cost?” doesn’t necessarily need an LLM inventing a confident answer. They need a structured estimate based on things such as size, placement, complexity, and color.

That led me to build a Tattoo Cost Calculator that treats the result as a planning range rather than pretending there is one exact price.

Lettering gave me a similar lesson.

Sometimes a user doesn’t need an AI-generated lettering composition yet. They just want to see how the same word looks across different type directions.

For that, a fast deterministic Tattoo Font Generator can actually be more useful than spending time and compute generating another image.

Only when the user wants something less deterministic — custom composition, flourishes, ornamental treatment, integration with other elements — does the AI layer become much more valuable.

What surprised me is that this hasn’t made the AI part of the product less important.

It has made its job clearer.

I’m starting to think one of the easiest mistakes when building an AI product is asking:

“Where else can I add AI?”

when the better question is:

“Which parts of this workflow are actually uncertain enough to need AI?”

If the answer can be calculated, converted, previewed, or looked up reliably, a model call can introduce latency, cost, and unpredictability without adding much value.

AI becomes much more interesting when the problem contains ambiguity.

That sounds obvious written down, but it wasn’t obvious to me when I started building.

I initially thought of non-AI utilities as supporting features around the “real” AI feature.

Now I’m much less sure that hierarchy makes sense.

In some workflows, the boring deterministic tool may be the feature that gets the user to the point where AI is finally useful.

Curious how other people building AI products think about this.

Have you added a feature where the best implementation turned out to be less AI, not more?

on August 26, 2026
  1. 2

    This resonates a lot with something I just went through building AnchorStrategy (AI strategy reports with citation grounding).

    We had a bug where our citation-fidelity check relied purely on string similarity (an LLM-adjacent, probabilistic signal) to decide if a claim matched its source. Turns out that's exactly the "exact problem" category you describe — checking whether an entity/number in a claim actually exists in the source text is deterministic, not something a similarity score should be trusted to judge. We ended up adding a hard, rule-based gate (proper-noun/number token matching) in front of the probabilistic layer, and it caught real bugs that the "softer" approach missed.

    Your framing flips the usual question nicely: not "where can I add AI" but "which parts are actually uncertain enough to need it." I'd add one thing from our experience — even inside an "AI feature," there's often a deterministic sub-check hiding that's worth pulling out separately.

    1. 1

      That’s a great extension of the idea. I was mostly thinking at the tool level, but the same boundary clearly exists inside an AI feature too.

      Let the model handle the ambiguous part, then pull exact checks like entities, numbers, formats, or constraints into deterministic gates. Your citation example is a really good illustration of that.

      1. 1

        Thanks — and it's pushed us further than I expected. We ended up literally splitting that deterministic gate out into its own tiny standalone tool (paste an AI-generated claim next to its source, and it flags what the entity/number check catches). Your framing captures it well: the model does the ambiguous language work, the gate does the boring exact-match work, and neither should pretend to do the other's job.