At first, I thought the right way to improve my AI tattoo product was simple:
keep adding more features to the same tool.
More inputs.
More options.
More presets.
More “smart” behavior.
It sounded efficient.
One interface, one product, one place for everything.
In practice, it started making the product harder to understand.
The problem was not that the features were bad.
The problem was that they were solving completely different kinds of problems.
One interface was hiding several different workflows
A user trying to convert a date into Roman numerals is doing something very different from a user trying to explore a visual tattoo concept.
The first problem is exact.
The second is open-ended.
That distinction sounds obvious in hindsight, but I did not design around it at first.
I kept thinking in terms of features:
- add a Roman numeral option
- add font previews
- add cost guidance
- add lettering controls
- add image generation
Eventually I realized I was mixing several different input/output contracts into one product.
Some problems need exact answers
A Roman numeral conversion should not be creative.
If someone enters a date, the expected result should be deterministic and verifiable.
That is why I kept the Roman Numeral Tattoo Generator as a focused tool instead of turning the conversion itself into an AI prompt.
The important part is not “make something interesting.”
It is:
Give the same correct answer every time.
That means the useful features are things like:
- validating the input
- showing the converted result clearly
- supporting common date formats
- helping users compare spacing and presentation
AI would add uncertainty where uncertainty is not useful.
Some problems are really comparison problems
Tattoo lettering looked similar at first.
I originally treated text styling as something that belonged inside the AI generation flow.
But many users are not ready to generate a full composition yet.
Sometimes they just want to answer a simpler question:
What does this name or phrase look like in different styles?
That is a preview problem, not necessarily a generation problem.
So I separated that workflow into the Tattoo Font Generator.
It lets the user compare text styles first, before deciding whether they actually need AI-generated lettering.
The interface became simpler because the tool has one job:
show the text in different directions quickly.
Some problems are bounded estimates
Tattoo pricing is another example.
I could have sent a prompt to a language model and asked:
“How much will this tattoo cost?”
But that would create false precision.
Tattoo pricing depends on things like size, placement, style, complexity, location, and artist rates.
The useful output is not one confident number.
It is a planning range.
So the Tattoo Cost Calculator uses structured inputs and rules instead of pretending a model knows the final shop price.
That made the product more predictable and easier to explain.
AI became more useful when the problem became ambiguous
The AI part became much clearer once I stopped using it for everything.
If a user says:
“I want a blackwork tattoo involving a snake, flowers, and a dagger, but I am not sure how to combine them.”
That is not an exact-answer problem.
There are many valid compositions.
That is where the AI Tattoo Generator makes sense.
The model is useful because ambiguity is part of the task.
The user is not asking for a conversion or lookup.
They are exploring possibilities.
The architecture got better when the boundaries got clearer
This changed how I think about AI product architecture.
Instead of asking:
Where else can I add AI?
I now ask:
What kind of problem is the user actually trying to solve?
I roughly think about them like this:
| Problem type | Better approach |
|---|---|
| Exact transformation | Deterministic logic |
| Visual comparison | Preview UI |
| Bounded estimate | Structured calculator |
| Open-ended composition | Generative AI |
The implementation details are different, but the bigger benefit is product clarity.
Each tool can now have a cleaner contract.
The user understands what goes in, what comes out, and what level of uncertainty to expect.
Splitting the product felt less elegant at first
There is something attractive about a single AI interface.
It feels powerful.
It also makes the product diagram look simple.
But a simple architecture diagram does not always create a simple user experience.
Sometimes one “smart” tool becomes a collection of hidden modes, exceptions, and confusing controls.
Splitting the workflows made the code easier to reason about too.
Each part has clearer validation, state, output, and failure behavior.
And importantly, not every user action needs a model call.
That means less latency, lower cost, and fewer unpredictable results.
My current rule
If the problem has one correct answer, I try not to use AI.
If the problem has a constrained range of acceptable answers, I first look for structured logic.
If the value comes from exploring many possible answers, then AI starts becoming useful.
That sounds like a small distinction.
For me, it changed the product architecture.
I stopped trying to make one AI tool smarter.
I started making each tool more specific.
And the product became easier to understand because of it.
Have you built a feature that became better after you removed AI from part of the workflow?
