How I Learned to Build an AI Website Without Losing My Mind

When I first started learning how to build an AI-powered website, I thought the hardest part wold be the AI itself.

I imagined the process would be something like this:

Learn a little frontend.
Learn a little backend.
Call an AI model.
Display the result.
Done.

Of course, reality was not that polite.

At the beginning, I built a very simple AI demo site. The idea was basic: users type a prompt, the website sends it to an AI model, and then the result comes back. Nothing fancy. Just a small project to help me understand how AI products actually work.

The first version worked, and I was honestly pretty excited.

Then I started thinking, “What if I add image generation?”
Then, “What if I add video generation?”
Then, “What if users want different models?”
Then, “What if one model is too expensive?”
Then, “What if one API is slow or unstable?”

That was the moment I realized AI development is not just about writing prompts or calling one API.

The real difficulty is building a system that can keep changing.

Every AI provider seemed to have a different API format. Some models returned results immediately. Some returned a task ID and required polling. Some had strange error messages. Some had different authentication methods. Some were good but expensive. Some were cheap but unstable. Some were great for one use case and bad for another.

My code slowly started turning into a pile of provider-specific logic.

Something like:

if (model === "A") {
 // handle this weird request format
}

if (model === "B") {
 // handle this different response format
}

if (model === "C") {
 // why is this one async again?
}

It worked, but it felt fragile.

I didn’t want to spend all my time writing wrappers for different model providers. I wanted to focus on the product itself: the user flow, the interface, the generation history, the pricing logic, and the actual experience.

That was when I started looking for a more unified way to call AI models, and I found Crun.

What I liked about it was simple: instead of integrating many different AI APIs one by one, I could use one API layer to access different models for image, video, audio, and text generation.

This changed how I thought about the backend.

Instead of treating each AI model as a separate integration, I started treating AI generation as a product-level service.

The frontend does not need to know which model is being used.
The user does not need to know which provider is behind the result.
The backend just receives a generation request, creates a task, stores the task ID, and updates the result when it is ready.

My architecture became much cleaner:

User
 ↓
Frontend
 ↓
Backend
 ↓
AI service layer
 ↓
Crun
 ↓
Different AI models

This was a small mindset shift, but it helped a lot.

Now, if I wanted to test a different image model, I didn’t need to rewrite half of the system. If one model was too expensive, I could switch it. If users wanted video generation later, I could add it without redesigning everything.

I also learned an important lesson: AI generation should usually be handled as an asynchronous task.

At first, I wanted the user to submit a prompt and immediately get the result in the same request. That sounds simple, but it is not reliable for real AI generation.

Some tasks take seconds. Some take longer. Some fail. Some need to be retried.

So I changed the flow:

1. User submits a prompt
2. Backend creates an AI generation task
3. Backend stores the task ID
4. Frontend shows a loading state
5. Backend checks for the result
6. User sees the final output

This made the product feel much more stable.

But then I ran into the second problem.

Once people started trying the website, feedback came from everywhere.

A friend messaged me:
“Can you add a cheaper mode?”

Another person said:
“The result is good, but the waiting time feels too long.”

Someone else said:
“Can you support image-to-image?”

Then there were bug reports, random suggestions, UI complaints, and feature ideas.

At first, I put everything into a Notion page.

That worked for about two days.

Then I forgot to update it.

Some feedback stayed in chat messages. Some stayed in email. Some was in comments. Some was only in my memory, which is probably the worst database in the world.

The funny thing is, I was still improving the product, but users couldn’t see that.

From my side, I was fixing bugs and testing models.
From their side, it probably looked like nothing was happening.

That made me realize something important:

Building is not enough.
Users need to feel that the product is alive.

They need to know:

What feedback has been received?
What is being considered?
What is planned?
What has already been shipped?

That was when I started using FeedLog.

FeedLog helped me turn messy feedback into a more organized feedback loop. Instead of collecting ideas randomly from chat, email, and comments, I could send users to one place where they could submit feedback, vote on ideas, and see the roadmap.

The biggest benefit was not just “collecting feedback.”

The biggest benefit was reducing chaos.

When multiple users asked for similar things, I could see the pattern more clearly. A single loud user was no longer the only signal. I could look at repeated requests, votes, and discussions.

For example, instead of thinking:

“One person complained about generation speed.”

I could see:

“Actually, many users care about faster generation, even if they describe it differently.”

That changes product decisions.

It also helped with communication. When I shipped something, I could add it to the changelog. When I planned something, I could move it to the roadmap. Users could see that their feedback was not disappearing into a black hole.

That was a big lesson for me.

A product feedback system is not only for the team.
It is also for user trust.

When users submit feedback and never hear anything back, they slowly stop caring. But when they can see progress, they feel involved.

My current learning from this project is pretty simple:

For AI development, don’t tie your whole product too tightly to one model or one provider. Use an abstraction layer early, even if your first version is small.

For user feedback, don’t wait until everything becomes messy. Create a feedback loop before you feel like you desperately need one.

In my case, Crun helped me simplify the AI integration problem, and FeedLog helped me handle the feedback problem.

One helped me build faster.
The other helped me listen better.

And honestly, that combination made the whole learning process feel much less chaotic.

I still have a lot to learn. My code is not perfect. My product is not perfect. My architecture will probably change again.

But now I understand AI product development a little better.

It is not just about calling a powerful model.

It is about building a system that can keep improving.