From Prototype to Production: My CI/CD & AI Deployment Journey

One of the most useful parts of my GenAI journey hasn't been building the AI itself.

It has been learning what happens after the prototype works.

I recently deployed a Next.js application with a Python/FastAPI backend and OpenAI integration using Vercel and Git-based deployments. What looked simple at first became a crash course in CI/CD, cloud deployment, environment variables, dependency management and production debugging.

And that was exactly what I needed to learn.

From local machine to production

Locally, the application was straightforward:

Next.js frontend
↓
Python / FastAPI API
↓
OpenAI API

Everything worked.

Then came the real question:

Can I make it work reliably outside my laptop?

That introduced a completely different set of concerns.

CI/CD changed my perspective

Connecting the project to Git meant that the workflow became:

Code → Git → Build → Deploy → Test → Monitor

A code change could trigger a new deployment without manually copying files or configuring a server.

This seems simple, but experiencing the workflow end-to-end helped me understand an important principle:

Deployment is part of the product, not an afterthought.

A beautifully designed AI application isn't useful if it cannot be reliably built, deployed and maintained.

The first lesson: deployment environments matter

One of my early problems came from the deployment process itself.

The project contained far more files than expected, and Vercel's deployment limits became relevant.

This forced me to understand something I had previously taken for granted:

What is actually being sent to the cloud?

I learned to pay attention to:

• .gitignore

• Build output

• Dependencies

• Deployment size

• Framework configuration

• Environment-specific files

The solution wasn't simply "try deploying again."

It was understanding the build and deployment pipeline.

Environment variables aren't configuration details

The AI application required an API key.

Locally, I could use an environment variable and everything worked.

In production, the application could successfully deploy—but the AI request failed.

The logs eventually revealed the issue:

The application was running, but the OpenAI API account had no available credits.

This was a useful distinction.

Deployment succeeded.
The application ran.
The AI service still failed.

Production debugging requires separating these layers instead of treating every error as a deployment problem.

Logs became my new debugging interface

One of the biggest changes in my thinking was learning to use deployment logs systematically.

Instead of:

"The application doesn't work."

I started asking:

Did the build succeed?
Did the function start?
Were environment variables available?
Did the API receive the request?
Did the external AI service respond?
What exactly did the error say?

That mental model is extremely useful for AI applications because there are often multiple systems involved.

The AI deployment stack

My application became a small distributed system:

Browser
↓
Next.js / Vercel
↓
Python API
↓
OpenAI API
↓
LLM response
↓
Application UI

Every boundary introduces a potential failure.

And that means every boundary needs:

Logging · Error handling · Monitoring · Security · Fallbacks

What I learned about CI/CD

The biggest learning wasn't how to click "Deploy."

It was understanding the lifecycle:

Develop → Commit → Build → Deploy → Observe → Fix → Redeploy

That cycle is the foundation for maintaining modern AI products.

It also made me appreciate why production AI engineering is very different from a local prototype.

My UX perspective changed too

As a designer, I naturally think about the user's experience.

Deployment taught me to think about the system's experience as well.

A production AI product has multiple users:

The end user
needs a reliable experience.

The developer
needs useful logs and predictable deployments.

The product team
needs visibility into failures.

The organisation
needs security, cost control and governance.

Good AI product design needs to consider all of them.

What I'm learning next

My next step is to deepen this into a more complete production workflow:

CI/CD → Testing → Evaluation → Observability → Monitoring → Governance

For AI specifically, I want to go beyond simply asking:

"Does the application work?"

and start asking:

"Is the AI behaving correctly, consistently, safely and cost-effectively in production?"

The biggest takeaway

Building the AI is only half the job.

Getting it reliably into the hands of users—and knowing when and why it fails—is the other half.

That experience has moved my understanding of GenAI from building prototypes toward engineering products that can actually operate in production.