DEV Community: Warren

I Built a Roman Numeral Tattoo Generator, Then Realized Conversion Was the Easy Part

Warren — Wed, 22 Jul 2026 07:25:15 +0000

I thought a Roman numeral tattoo generator would be a very small feature.

The original workflow looked obvious:

Enter a date
Convert it into Roman numerals
Show the result
Let the user copy or download it

The conversion logic itself was not difficult.

What surprised me was that users were not really asking only:

What is this date in Roman numerals?

They were also asking:

Will this still work as a tattoo?

That second question changed the product.

The first problem was not Roman numerals

It was date ambiguity.

A date like:

04/11/1992

can mean:

April 11, 1992
November 4, 1992

Both interpretations are valid depending on the user’s country.

A converter can produce a mathematically correct result for the wrong intended date.

The safer workflow begins with the date written in words:

April 11, 1992

Then each section can be converted separately:

4 → IV
11 → XI
1992 → MCMXCII

The final month-day-year version becomes:

IV · XI · MCMXCII

The conversion is correct only after the date order is clear.

Roman numerals do not preserve modern digits

Another source of confusion is zero.

Traditional Roman numerals do not have a standard symbol for zero.

That means:

09 → IX
2004 → MMIV
2020 → MMXX

Users sometimes expect every modern digit to remain visible in the converted result.

Roman numeral conversion works with the value of the complete number, not each individual digit.

This is a small historical detail, but it matters when the result may become permanent.

Correct conversion was still not enough

Once the date was correct, the next questions appeared:

Should the date use dots, slashes, or spaces?
Should it be month-first or day-first?
Should the full date be used, or only the year?
Will the chosen font remain readable at tattoo size?
Is the date too long for the wrist?
Should the layout be horizontal or stacked?
Will repeated I characters merge together?
Is the preview a design idea or a final stencil?

At that point, the tool was no longer just a converter.

It had become a small planning workflow.

Separators change the design more than expected

The same date can look very different depending on the separator:

IV · XI · MCMXCII
IV / XI / MCMXCII
IV – XI – MCMXCII
IV | XI | MCMXCII
IV XI MCMXCII

Dots feel compact and classical.

Slashes resemble a modern written date.

Spaces create a minimal look, but the date sections may become less obvious.

Vertical lines create stronger separation, but they can also resemble the Roman numeral I.

A tiny separator that looks clear on a large screen may nearly disappear when the design is reduced to tattoo size.

Punctuation is not only decorative. It affects readability.

Font previews can be misleading

A Roman numeral date often contains repeated straight characters.

For example:

VIII · III · MMXXIII

This can look clear in a large digital preview.

At a smaller physical size, the repeated I characters may become difficult to count.

Decorative fonts create additional risks:

Thin serifs may disappear
Gothic details may merge
Script flourishes may cross the numerals
Narrow spacing may make separate date sections look connected

A visually impressive font is not automatically a practical tattoo direction.

The user still needs to evaluate the design at approximately the intended physical size.

Placement changes the format

A short year such as:

MMXXIV

can fit into many small placements.

A full date such as:

XII · XXVIII · MMXXIV

needs significantly more width.

Trying to force both into the same small wrist layout usually means:

Smaller characters
Tighter spacing
Thinner lines
Less readable separators

A stacked layout may work better:

XII
XXVIII
MMXXIV

The user may also decide that the year alone carries enough meaning.

The best format depends on the body area, not only the number.

A generated image is not a final tattoo stencil

This became an important product boundary.

A digital preview can communicate:

The date
The general font direction
Spacing preferences
Separator style
Horizontal or vertical layout
Supporting visual details

But it does not fully account for:

Body curvature
Physical line thickness
Skin movement
Healing
Long-term readability
The tattoo artist’s technique

So I stopped describing the output as a final tattoo design.

The more accurate role is:

A visual reference to discuss with a tattoo artist.

The artist may still redraw the lettering, increase the spacing, simplify details, or change the size.

That is not a failure of the generator. It is part of adapting a digital concept to skin.

I separated it from the general tattoo generator

Originally, Roman numerals could have remained one option inside a larger AI tattoo tool.

But the user intent was different.

Someone searching for a Roman numeral tattoo usually already knows the core subject.

They are not asking the system to invent a dragon, flower, or abstract concept.

They need help with a narrower sequence:

meaningful date
→ correct conversion
→ visual format
→ readable reference
→ artist discussion

That justified a dedicated page and workflow.

It also made the interface simpler.

The tool did not need every control from the general tattoo generator. It needed controls and explanations specifically related to dates and lettering.

The SEO lesson was similar

At first, I treated several search terms as variations of the same keyword:

Roman numeral converter
Roman numeral tattoo generator
Roman numeral tattoo font
Roman numeral date tattoo
Roman numeral tattoo creator

But the intent behind them is not identical.

A generic converter answers:

What number does this become?

A tattoo-focused tool must also address:

How should this date be presented?

That includes:

Format
Style
Spacing
Readability
Placement
Verification

The most useful landing page is not the one that repeats “Roman numeral tattoo generator” the most.

It is the one that resolves the decisions hidden inside that search.

The product improved when it made fewer promises

The earliest framing was close to:

Generate a Roman numeral tattoo design.

That sounds stronger, but it is also less accurate.

The current framing is closer to:

Convert a meaningful date, compare visual directions, and prepare a clearer reference for your tattoo artist.

This is less dramatic, but it reflects the real workflow better.

It also avoids implying that a digital preview should be tattooed directly.

What I would build first now

If I were rebuilding the feature from the beginning, I would prioritize:

An unambiguous date input
Clear month-day-year and day-month-year handling
Separate conversion of the month, day, and year
Full-date and year-only comparisons
Several simple separator formats
Readability guidance
A clear “visual reference, not final stencil” boundary
A compact summary the user can discuss with an artist

I would not begin with dozens of decorative styles.

Correctness and clarity are more valuable than visual variety when the output represents a permanent date.

The broader lesson

The code that converts a date into Roman numerals was the easiest part.

The real product work was identifying all the decisions surrounding that conversion.

This pattern appears in many small tools.

A user may arrive asking for a simple output, but the useful product often needs to support the next decision as well.

For this tool, the real workflow was not:

date → Roman numerals

It was:

date
→ verified meaning
→ Roman numeral format
→ readable visual reference
→ tattoo artist adaptation

I eventually turned that workflow into a small Roman numeral tattoo generator.

The conversion still takes seconds.

Understanding what the user actually needs around it took much longer.

I Split One Tattoo Text Tool Into Three Different Workflows

Warren — Fri, 17 Jul 2026 03:43:37 +0000

At first, I assumed every tattoo text tool could share one simple workflow:

Enter text, choose a style, and preview the result.

That assumption worked for an early version.

It also created a product that was too broad.

A person comparing fonts, a person planning a name tattoo, and a person asking AI to create custom lettering may all type words into a box, but they are not trying to complete the same task.

Over time, I split the original idea into three workflows:

Tattoo font preview
Name tattoo planning
AI tattoo lettering composition

The interfaces still overlap, but the expected outputs are very different.

Workflow 1: Previewing tattoo fonts

The first user already knows what text they want.

Their main questions are usually:

What does this word look like in script?
Is Old English too heavy?
Will this date remain readable?
Should I use serif, sans serif, or handwritten lettering?
Can I download a simple preview?

This does not require AI generation.

It needs a fast font workbench:

Enter the text
Browse font categories
Adjust the size
Compare readable options
Download a simple preview

The output is intentionally limited.

It is a font reference, not a custom tattoo composition.

That distinction matters because adding flowers, shadows, frames, symbols, and decorative flourishes would make the tool slower and less predictable for users who only want to compare letterforms.

Workflow 2: Planning a name tattoo

A name tattoo sounds like a font problem, but it often becomes a structure problem.

Different inputs behave differently:

A short first name
Initials
Two names joined by an ampersand
A hyphenated name
A name with a date
A longer multi-word phrase

For example, Mia can support expressive script lettering.

A.B. 2014 usually needs a more compact and structured direction.

Mia & Noah introduces balance between two names.

Anne-Marie should not be treated the same way as two separate words.

The useful part of a dedicated name workflow is not showing every available font. It is helping the user decide what kind of lettering direction fits the structure of the name.

That led me to build a focused Name Tattoo Generator that classifies the input and recommends a smaller set of directions.

It does not try to replace the full font browser.

It acts as a planning entry point.

Workflow 3: Generating custom tattoo lettering

The third user wants something beyond a font preview.

They may ask for:

A name with flowers
A date with ornamental framing
Chicano lettering with soft shading
A phrase with controlled flourishes
Initials combined with symbols
A memorial composition
A custom arrangement rather than a plain text sample

This is where AI generation becomes useful.

It also introduces a difficult problem: the model must distinguish between text that must appear and visual instructions that must not appear as extra words.

A user might enter:

Exact Text:
Amelia

Then add:

Supporting Details:
Soft shading, subtle drips, wider spacing

Without a clear boundary, the model may try to render parts of the supporting description as text.

The interface therefore separates two fields.

Exact Text

The characters that must appear exactly.

Supporting Details

Instructions about decoration, spacing, mood, shading, symbols, and composition.

The AI Tattoo Lettering Generator then builds a visual reference while trying to preserve the exact text character by character.

This is a different product job from choosing a font.

The output is no longer a simple preview. It is a custom visual direction that can support a later discussion with a tattoo artist.

Search data exposed the overlap

One reason I revisited the product structure was that search engines continued associating name, font, lettering, and text-related queries with the same broad font page.

Queries such as these can look similar:

tattoo font generator
name tattoo generator
tattoo lettering generator
tattoo text generator
tattoo name creator

But the interfaces implied by those searches are not identical.

A font generator should optimize for comparison.

A name generator should optimize for guidance.

An AI lettering generator should optimize for custom composition.

Trying to make one page serve every variation can produce a page that mentions everything but performs no single task particularly well.

Splitting pages is not always the answer

This does not mean every keyword deserves its own route.

Creating separate pages for small wording differences would produce thin and repetitive content.

The split only made sense because the three workflows had different:

User intent
Interface requirements
Output formats
Product boundaries
Next actions

The test I now use is:

Would this user need a meaningfully different workflow, or only different wording?

When the workflow is the same, it should probably remain one page.

When the controls and expected result are genuinely different, a separate tool may be justified.

The broader lesson

Many products begin with a broad input box because it is the fastest way to ship.

That is useful for testing.

But one input box can hide several distinct jobs.

The next stage is not always adding more options to the same screen. Sometimes it means removing options and creating clearer paths.

In this case, the final structure became:

Font preview
→ Compare letterforms

Name planning
→ Choose a suitable direction

AI lettering
→ Build a custom visual composition

The tools are related, but they no longer pretend to be the same product.

That separation has made the interfaces easier to explain, easier to maintain, and more honest about what each output can actually do.

What I would do differently next time

I would still start with one broad workflow.

It is often the fastest way to learn whether users care about the problem at all.

But I would pay closer attention to where users begin asking for different outcomes.

Some users want speed and predictability.

Some want guidance.

Some want a custom generated composition.

Those differences should eventually appear in the interface.

A broad MVP is useful for discovery.

A clearer set of focused workflows is useful for growth.

For AIMakeTattoo, the separation now looks like this:

Use the font workflow to compare letterforms
Use the name workflow to narrow down a direction
Use the AI lettering workflow to create a more customized visual reference

The next challenge is not adding more options.

It is making each path easier to discover and making the handoff between them feel natural.

Google Indexed My Pages. Nobody Found Them.

Warren — Tue, 09 Jun 2026 09:16:12 +0000

A few weeks ago I thought I had a technical SEO problem.

Pages weren't showing up.

Search Console looked empty.

So I spent a lot of time worrying about indexing.

Then the pages finally got indexed.

Nothing happened.

That was the moment I realized indexing and understanding are completely different problems.

I'm building a small browser-side utility.

The product removes metadata from photos and documents.

From a technical perspective the site was fine.

Pages were crawlable.
Sitemap was submitted.
Search Console showed indexing progress.

But search traffic still barely moved.

At first I thought Google needed more time.

Then I started looking at the queries that actually appeared.

Something interesting showed up.

Users searched for things like:

"remove location from photo"

"remove gps from image"

"remove author from pdf"

Almost nobody searched for:

"metadata processing"

"metadata extraction"

"browser-side metadata cleanup"

Those were the phrases I had been using when describing the product.

The product and the user were talking about the same thing.

Just in completely different languages.

That changed how I think about SEO.

I used to assume:

Indexing
→ Ranking
→ Traffic

Now it feels more like:

Indexing
→ Understanding
→ Ranking
→ Traffic

And the understanding step is surprisingly slow.

Especially for small sites.

The weird part is that AI makes this easier to miss.

Building is cheaper than ever.

Adding another page takes minutes.

Adding another feature takes hours.

Adding another tool feels almost free.

So it's easy to create more things.

But search engines still need to understand what those things are.

Lately I've been spending less time building pages and more time trying to understand how users describe the problem in their own words.

That has probably taught me more than any SEO guide I've read so far.

AI makes building faster, but semantic distribution is now the hard part

Warren — Thu, 21 May 2026 04:49:33 +0000

Shipping products feels dramatically easier now.

Between AI coding tools, templates, and browser-side tooling, I can build and deploy things faster than ever.

But distribution feels harder.

Not technically harder.

Semantically harder.

A lot of the work now is:

understanding how users actually search
matching workflows instead of technical terms
figuring out where intent really exists
building trust before distribution channels suppress you

Building became compressed.

Attention became fragmented.

Honestly feels like distribution is becoming the real product skill now.

Most people search “remove location from photo”, not “EXIF”

Warren — Fri, 15 May 2026 08:49:20 +0000

Most people search “remove location from photo”, not “EXIF”

While building a metadata removal workflow, I realized something interesting:

Most people never search for:

EXIF
IPTC
document properties
metadata

They search for:

“remove location from photo”
“hidden info in PDF”
“remove GPS from image”
“does this file still contain private data?”

The technical layer and the user intent layer are often completely different.

Developers think in systems.

Users think in outcomes.

That changed how I started thinking about both SEO and product design.

A lot of users are not trying to “inspect metadata”.

They’re usually just at the moment before sharing something publicly and wondering:

“wait… is there still something hidden in this file?”