DEV Community: Warren

I Almost Used AI to Classify User Input. Simple Rules Worked Better

Warren — Sat, 15 Aug 2026 01:56:06 +0000

I’ve been rebuilding a small name tattoo tool recently, and I ran into a problem that looked like a good use case for AI.

The user enters some text.

At first, I treated every input basically the same:

text → show a set of lettering styles

That works for simple names.

But these are all very different inputs:

Emma
A.M.
Jack + Mia
Amelia · 1998-11-14
Anna-Marie
Forever Dad

Showing the exact same recommendations for all of them started to feel wrong.

My first thought was: classify the input with an LLM.

I already use AI elsewhere in the product, so sending the text through another model call would have been easy enough.

But after listing the cases I actually cared about, I realized the classification problem was tiny.

The input types were predictable

I didn’t need to understand arbitrary human language.

I mostly needed to distinguish things like:

initials
initials + date
name + date
two names
hyphenated names
multi-word text
short single names
medium single names
long single names

So instead of adding another model call, I used deterministic rules.

A simplified version looks roughly like this:

function getNameStructure(text: string) {
  const value = text.trim()

  if (looksLikeInitialsAndDate(value)) {
    return "initials-date"
  }

  if (looksLikeNameAndDate(value)) {
    return "name-date"
  }

  if (looksLikeInitials(value)) {
    return "initials"
  }

  if (looksLikeNamePair(value)) {
    return "name-pair"
  }

  if (value.includes("-")) {
    return "hyphenated"
  }

  if (value.split(/\s+/).length > 1) {
    return "multi-word"
  }

  if (value.length <= 5) {
    return "short"
  }

  if (value.length <= 9) {
    return "medium"
  }

  return "long"
}

The real implementation has a few more checks, especially around dates and separators, but the idea is the same.

Nothing clever.

And that turned out to be a good thing.

Classification only mattered because it changed the UI

I didn’t want classification for its own sake.

I wanted the first few lettering options to make more sense for the input.

For example, compact initials can tolerate directions that might feel too heavy for a long name.

A name pair needs enough spacing to keep both names readable.

A name + date has a second piece of information competing for attention.

A long name usually needs a little more restraint than a short one.

So the structure changes the recommendation order.

Something like:

const recommendations = {
  initials: [
    "bold",
    "minimal",
    "gothic",
  ],

  "name-pair": [
    "minimal",
    "script",
    "serif",
  ],

  "name-date": [
    "serif",
    "minimal",
    "script",
  ],

  short: [
    "script",
    "signature",
    "bold",
  ],
}

The exact presets aren’t important here.

What mattered was that recommendations became predictable.

And I still keep the other styles visible.

The classifier doesn’t decide:

This is the correct style for your tattoo.

It only decides:

These are probably useful directions to show first.

That distinction helped keep the rules small.

Why I ended up preferring rules over AI here

The more I worked on it, the less attractive an AI classifier became.

With deterministic rules:

there’s no extra inference cost
there’s no network latency
the same input always gets the same classification
edge cases are easy to reproduce
I can see exactly why a recommendation appeared
changing product behavior means changing a rule, not changing a prompt and hoping the model interprets it the same way

Most importantly, the problem itself wasn’t fuzzy enough to justify a model.

The product still uses AI when the user wants an actual custom lettering composition with flowers, symbols, flourishes, or other supporting details.

But deciding whether A.M. looks like initials?

That doesn’t need intelligence.

It needs a regex.

I ended up using this approach in the Name Tattoo Generator, where the lightweight preview stays deterministic and the AI step only comes later when the user actually wants custom composition.

I think I was using the wrong default

For a while my default question was:

Could AI handle this?

Now I’m trying to ask:

Is there enough uncertainty here that AI is actually useful?

If the input space is small, the rules are understandable, and predictability matters, a boring classifier can be a better product decision.

AI is much more valuable later in this workflow, where the user asks for something genuinely open-ended.

The funny part is that making the AI product better in this case meant using less AI.

I’m curious how other people draw this line.

What’s something you originally planned to solve with an LLM, then replaced with normal code?

I Thought I Was Building an AI Image Generator. I Was Actually Building an Iteration System.

Warren — Fri, 07 Aug 2026 09:29:27 +0000

I started with a pretty simple mental model for my AI image product:

A user enters an idea, chooses a few options, generates an image, and either likes it or tries again.

That model turned out to be too shallow.

Once people started using the product repeatedly, the behavior looked less like “generate another image” and more like “keep narrowing the decision.”

They would keep the core idea and change one variable:

a different style
a different placement
a narrower or wider proportion
a different supporting element
less detail
a different lettering direction

That changed how I think about the product.

The generated image is not always the final unit of value.

Sometimes the real value is the sequence of comparisons that helps the user decide what they actually want.

Generation is only one step

The obvious architecture for an AI image product looks something like this:

input
  ↓
generation
  ↓
result

But the real user workflow often looks more like this:

idea
  ↓
generate
  ↓
compare
  ↓
change one variable
  ↓
generate again
  ↓
compare again
  ↓
narrow the direction

That is a different product.

If the user is iterating toward a decision, several things become more important than simply adding more model choices.

1. Controls become part of the reasoning interface

A prompt box gives users freedom, but it also asks them to describe everything again.

Structured controls let them preserve most of the current idea while intentionally changing one dimension.

In my case, things like style, placement, proportion, and detail level became more useful than I initially expected.

They are not just generation parameters. They are comparison variables.

A user can effectively ask:

same idea
+ different placement

or:

same subject
+ narrower composition

without rewriting the whole concept.

That makes the UI part of the reasoning loop.

2. “Regenerate” is a very blunt tool

Most generative interfaces have some version of a regenerate button.

But full regeneration throws away a lot of information.

A user may like:

the composition
the main subject
the balance
the general style

and dislike only one thing.

If every retry regenerates the whole image, the user has to trade one improvement for several accidental changes.

What they really want may be closer to this:

keep:
- composition
- subject

change:
- color

or:

keep:
- style
- main element

remove:
- supporting symbol

That is much closer to editing than random regeneration.

3. History is not enough

I recently added a lightweight generation history feature.

It solves retrieval well. A user can find an earlier result, open it again, download it, or compare it with something newer.

But history by itself does not create iteration.

There is an important difference between:

find an old result

and:

continue from this result

The second one requires more state.

Potentially:

generation state
- original input
- selected controls
- tool type
- model/provider
- relevant assets
- previous result

And even that only gets you to continuation.

Controlled variation is another layer again.

4. Credits are not always paying for outputs

This was another assumption I had to change.

The simple interpretation of generation credits is:

1 credit = 1 more output

But in an iterative workflow, credits can represent something closer to:

more room to explore

The user may not need ten finished images.

They may need ten attempts to answer questions like:

Which placement works?
Which composition feels right?
Is this too detailed?
Do I prefer this style or the previous one?
What should I bring to the next step?

That changes how I think about both pricing and UX.

If the user is paying for iteration room, the product should make each iteration easier to compare and more intentional.

5. Better models do not automatically fix this

It is tempting to solve every problem in an AI product by improving the model.

Better image quality helps. More reliable instruction following helps.

But neither solves the workflow problem.

A stronger model still does not know which part of the previous result the user wants to preserve unless the product gives them a way to express that.

This is why I am becoming more interested in:

preserving generation state
comparing related outputs
restoring prior controls
creating branches
controlled variation
keeping selected parts while changing others

than simply adding more styles or another model.

The architecture starts changing

Once you treat the product as an iteration system, the data model starts looking different too.

A generation is no longer just:

id
image_url
created_at

It starts looking more like:

generation
- user
- tool
- input state
- selected controls
- output
- parent generation
- model metadata
- created time

You may not need all of this on day one.

I definitely do not.

But the important part is recognizing that a result may eventually need context about where it came from and what it is related to.

Otherwise, history becomes a pile of disconnected images.

The shift for me

I used to think the core loop was:

prompt → image

Now I think it is closer to:

idea → generation → comparison → refinement → decision

That sounds like a small wording difference, but it changes what I prioritize.

The product is not only responsible for producing an image.

It is also responsible for helping the user move between attempts without losing the reasoning that got them there.

I ran into this while building the AI Tattoo Generator in AIMakeTattoo.

I am still keeping the system lightweight, but I am much less interested now in “how many outputs can this generate?” and more interested in “how easily can someone move from one useful attempt to the next?”

For people building generative products: what ended up mattering more in your product — better generation quality, or better iteration controls?

I Added Image Upload to an AI Product. The Hard Part Was Everything Around It.

Warren — Fri, 31 Jul 2026 02:40:12 +0000

I recently added an Image to Tattoo workflow to AIMakeTattoo.

From the user’s perspective, the feature looks straightforward:

Upload a photo or sketch.
Choose a tattoo style.
Adjust proportion and complexity.
Generate a tattoo design.

From the application’s perspective, image upload introduced a much larger set of concerns:

multipart request parsing
file validation
image moderation
anonymous and signed-in quotas
paid credits
concurrent-job protection
provider uploads
OAuth state loss
privacy decisions
cleanup after partial failure

The image generation request itself was one of the easier parts.

Image upload changed the request boundary

The existing text-to-image flow accepted structured fields.

The server could validate the prompt and selected controls, check whether the user was eligible to generate, submit a job, and return a job ID.

Adding a file changed that boundary.

The route now had to answer several new questions:

Which file types should be accepted?
How large can an individual image be?
Should the complete multipart request have its own size limit?
When should moderation run?
Should an ineligible request reach moderation at all?
Should the application store the original image?
What happens when the user signs in after choosing a file?
Which failures require releasing a generation lock?
At what point should a paid credit be consumed?

None of these questions directly improved the generated image.

They determined whether the feature behaved like a reliable part of the product.

The first request flow worked, but it did unnecessary work

My initial flow was roughly:

Parse the multipart request.
Resolve the user or anonymous visitor.
Acquire an active-generation lock.
Moderate the uploaded image.
Check free quota and paid credits.
Upload the image to the generation provider.
Submit the generation job.
Store the job metadata.
Consume the correct allowance.

The happy path worked.

But a user who had clearly exhausted every available allowance could still reach image moderation before the request was rejected.

That meant the application was doing work for a generation that could never proceed.

I added an early eligibility check

I moved a read-only eligibility check closer to the beginning of the request.

The revised flow became:

Parse and validate the request.
Resolve the user or anonymous visitor.
Read the current allowance and credit state.
Reject requests that are obviously ineligible.
Acquire the active-generation lock.
Moderate the image.
Run the final authoritative eligibility checks.
Upload the image and submit the generation job.
Persist the job metadata.
Consume the correct allowance or credit.

The early check can reject obvious cases, such as:

an anonymous visitor who has exhausted the daily allowance
a signed-in user who has reached the relevant limit
a user with no free generations and no paid credits

But this early check is deliberately advisory.

It does not consume anything, and it does not authorize the final generation.

It only answers:

Is this request clearly unable to continue?

Why the early check cannot be authoritative

A quota read can become stale immediately.

Suppose a user has one free generation remaining and sends two requests at nearly the same time.

Both requests may see the same initial state.

A paid-credit balance can also change between the early check and the point where the provider job is submitted.

The final check therefore answers a different question:

Is this request allowed to consume a generation right now?

The two checks may look repetitive, but they have different responsibilities.

The early check avoids unnecessary work.

The final check protects the state change.

This also means the advisory check should fail open when it cannot make a confident decision. A temporary problem in an optimization step should not become a new reason to reject legitimate users.

The lock created the most dangerous failure mode

AIMakeTattoo allows only one active generation per user.

That reduces accidental double submissions and prevents concurrent requests from trying to use the same allowance.

The route acquires an active-job lock before the expensive part of the workflow.

The obvious rejection paths released that lock correctly.

The more dangerous issue was an unexpected exception after the lock had already been acquired.

For example:

The user starts a generation.
The application acquires the lock.
The moderation service throws unexpectedly.
The request fails.
The lock remains.
The next attempt is rejected because the application still thinks a job is active.

The original failure may have been temporary.

The leaked lock turns it into a persistent product problem.

Every post-lock operation needs a cleanup path

The lesson was broader than image moderation:

Once a lock has been acquired, every later operation must live inside a cleanup boundary.

That includes failures during:

moderation
final quota validation
paid-balance validation
provider upload
provider job submission
local job persistence
allowance or credit consumption

The simplified structure looks like this:


ts
const lock = await acquireActiveJobLock(userKey);

try {
  await moderateImage(file);
  await runAuthoritativeEligibilityChecks(user);
  await uploadAndSubmitGeneration(file, controls);
  await persistJobMetadata();
} catch (error) {
  await releaseActiveJobLock(lock);
  throw error;
}

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?”