Building an Photo Tool Taught Me That the Model Is Only Half the Product

Over the last few weeks, I’ve been building an photo product.

At first, I thought the hard part would be the image model.

Which model gives the best quality?
How much does each generation cost?
How do I handle edits versus generation?
How do I keep latency acceptable?

Those questions matter.

But after building more of the product, I realized something else:

the image model is only half the product.

The other half is everything around it.

The first version looked fine, but felt wrong

My first instinct was pretty standard.

User enters a prompt.

The backend sends it to an image model.

The UI shows a loading state.

The result comes back.

Technically, it worked.

But it did not feel like an “AI agent.”

It felt like a form connected to an API.

That difference is bigger than I expected.

Users now have a strong mental model for conversational AI products.

They expect:

• their message to appear immediately
• uploads to feel like part of the conversation
• progress to be visible
• previous context to remain available
• follow-up instructions to work naturally
• the interface not to “reset” mentally after every request

Once you notice these expectations, a lot of small UX problems suddenly become obvious.

Loading states matter more than I expected

One thing I underestimated was how damaging bad loading behavior can be.

If the user sends a message and the interface briefly shows:

“Agent is thinking…”

then removes it,

then shows something else,

then disappears again,

then finally shows the result,

the product feels unstable.

Even if the final image is good.

The user has no idea what is happening.

I ended up caring much more about continuity.

The ideal experience is closer to:

1. User sends a message.
2. The message appears immediately.
3. A persistent response state appears underneath.
4. Progress remains visually stable.
5. The final image replaces the loading state cleanly.

This sounds trivial compared with model selection.

It is not.

For slow AI operations, UX becomes part of perceived intelligence.

Uploads are part of the conversation too

I ran into a similar problem with image uploads.

Originally, uploading felt like a separate system action.

You selected a file, then a small status message appeared somewhere else in the UI.

That broke the conversation.

The better mental model was:

the uploaded image is a message.

Once I started thinking about it that way, the UI decisions became easier.

The upload should appear directly in the conversation.

The user should see which image is currently active.

The system should make it obvious what the next edit applies to.

That is especially important when users start generating multiple versions.

Version history quickly becomes necessary

A simple AI image tool can get away with showing only the latest result.

A conversational one cannot.

Imagine this sequence:

“Make the background white.”

“Try a darker background.”

“Actually, go back to the first version.”

Now the application needs to understand what “first version” means.

Or:

“Keep the product from this version but use the lighting from the previous one.”

That is where the problem becomes less about generation and more about state.

You need some representation of:

• original uploads
• generated images
• edit relationships
• current selection
• previous versions
• conversation messages
• pending tasks

That made me rethink the database earlier than I expected.

I had assumed most of the complexity would live in prompt engineering.

A lot of it ended up living in application state.

“Agent” can become meaningless very quickly

Another thing I noticed while building is how loosely the word “agent” gets used.

A normal prompt box with an AI API behind it can easily be labeled an agent.

But from a product perspective, I think users only really feel the difference when the system maintains context and helps carry work forward.

For an image product, that means things like:

• knowing which image is being edited
• remembering recent instructions
• preserving useful context
• allowing multi-step refinement
• recovering from failed generations
• keeping project history intact

Without those things, the “agent” label does not add much.

Model quality still matters, but workflow can hide its weaknesses

One unexpected lesson was that a strong workflow can make an imperfect model much more useful.

A single generation may not be perfect.

But if the user can easily say:

“Keep everything else, but fix the lighting.”

or:

“Try another version.”

or:

“Make the background simpler.”

then the product does not need every first result to be perfect.

Iteration becomes part of the value.

That changed how I thought about model quality.

The important question is not just:

“How often does the model get it right on the first try?”

It is also:

“How quickly can the user recover when it does not?”

That is a much more product-oriented metric.

Cost design becomes part of UX too

Image generation is much more expensive than chat.

That creates another product challenge.

If every action costs real money, the pricing system affects user behavior immediately.

I found it useful to separate cheap conversational interactions from expensive generation actions.

The user should be able to clarify what they want without feeling like every sentence consumes paid credits.

Otherwise, people become hesitant to interact.

That is bad for a conversational product.

If the product wants users to iterate, the pricing model should not punish iteration unnecessarily.

The homepage matters less than the first successful edit

I spent a lot of time thinking about landing page design.

Hero layout.

Colors.

CTA buttons.

Showcase images.

All of that matters.

But I increasingly think the real activation event is much simpler:

the first time a user uploads or generates an image, asks for a change, and gets a result that feels useful.

That moment communicates the product better than almost any marketing copy.

So I’ve started thinking more about reducing friction between signup and that first useful edit.

The homepage should probably do less explaining and more moving people toward that moment.

This also changed how I think about retention

The obvious retention strategy for an AI image tool is “make the outputs better.”

But there may be another layer.

If users build up:

• image history
• project history
• preferred styles
• previous generations
• reusable prompts
• editing context

then the product starts accumulating value for them.

That can matter more than a slightly better model elsewhere.

A competitor can copy features.

It is harder to copy a user’s accumulated working context.

That feels like a more interesting long-term product moat.

I’m still testing the idea

The project I’m building is called PhotoAgent.

The current direction is centered around conversational image generation and editing, but I’m still figuring out which parts users actually care about most.

The biggest lesson so far is that building an AI product is not mainly about connecting a model.

It is about designing the layer between the model and the user.

That layer includes:

• state
• latency handling
• memory
• versioning
• pricing
• feedback loops
• UI continuity

The model gets most of the attention.

But the surrounding product experience is where a lot of the real differentiation seems to happen.

Curious if others building AI products have found the same thing.

What part ended up being harder than you expected: the model layer, or everything around it?