What Happens When a Non-Engineer Starts Building and Shipping With AI?

I am not an engineer.

But somewhere along the way, I started building things that I never thought I would be capable of building.

A few years ago, if you had asked me to build a website, I would have probably opened an HTML file, written some CSS, added a little JavaScript, opened it in my browser and felt pretty good about myself.

And honestly, I was.

Because for someone who wasn't an engineer, getting a webpage to work felt like an achievement.

Today, that same approach feels almost amusing.

I can now build a proper web application with a modern frontend using Next.js, connect it to a Python backend, work with databases and APIs, integrate open-source tools such as Sanity, use AI models through platforms like OpenRouter, and deploy the whole thing into the cloud.

And the funny part?

I still don't consider myself an engineer.

So, what changed?

AI.

But not quite in the way people usually describe it.

I didn't suddenly learn how to code.

I learned how to build with code.

There is a difference.

I can read code. I can understand what different parts of an application are doing. I can make changes. I can debug. I can reason about how the pieces should fit together.

But if you put a completely blank code editor in front of me and said, “Build this entire application from scratch without AI,” I would probably start looking for the nearest engineer.

And I'm completely comfortable admitting that.

Because my goal was never to become a software engineer.

My goal was to solve problems.

AI simply changed how far I could go in solving them myself.

I don't start with code. I start with the problem.

This is probably the biggest thing I have learned.

When I build something today, I don't start by thinking:

Should I use React? Next.js? Python? Node? Which database? Which framework?

Those questions eventually matter.

But they aren't where I start.

I start with:

What am I trying to solve?

What should the user be able to do?

What should the experience feel like?

What is the outcome I am trying to achieve?

Then I start looking for examples.

I don't draw elaborate screens from scratch.

I look around.

Figma Community.

Framer.

Dribbble.

Pinterest.

GitHub.

Open-source projects.

Websites I come across.

Sometimes I find an interface I like. Sometimes it's a particular interaction. Sometimes it's simply a design pattern that makes me think, “That's a much better way of doing this.”

Then I bring those references into the conversation with AI.

Screenshots.

Links.

Examples.

Descriptions.

My own requirements.

And I tell it what I'm actually trying to accomplish.

My game isn't just prompting. It's context.

The better context I provide, the better the collaboration becomes.

From HTML to actual applications

This is probably the easiest way for me to describe how much things have changed.

Earlier: HTML, CSS and a little JavaScript.

Then: React and modern frontend development.

Now: Next.js frontend, Python backend, APIs, databases, authentication, cloud infrastructure and whatever other tools the problem actually requires.

And I'm not restricted to writing everything myself either.

There are amazing open-source tools available for things I would never have attempted to build from scratch.

Take something like Sanity.

Instead of spending weeks thinking about how to build a content management system, I can understand what Sanity provides, decide whether it fits my use case, integrate it into the application and move on.

That's another major shift for me.

I don't need to reinvent every wheel.

I need to know which wheel I need, where to find it, and how to put it on the car.

AI makes that process much easier because I can ask questions that would previously have stopped me completely.

“What does this tool do?”

“How do I integrate it with Next.js?”

“What is the architecture here?”

“Why am I getting this error?”

“Is there an open-source alternative?”

“Can I do this serverlessly?”

And then I experiment.

I learned by building, not by waiting to learn everything first

My first major lesson was getting something to run on localhost.

And yes, before anyone comes after me:

I don't consider localhost a deployment.

But it was where the journey started.

Then came connecting the frontend and backend.

Then databases.

Then authentication.

Then APIs.

Then deploying.

Then figuring out what happens when something breaks after deployment.

Then logs.

Then permissions.

Then security.

Then scalability.

You learn one layer because the previous layer created a new problem.

And strangely, that has been much more effective for me than trying to learn everything upfront.

I didn't need to understand cloud architecture before building my first application.

I needed to build something first.

Then I had a reason to understand cloud architecture.

My first proper web app

Recently, I came across tools charging around $100 for Reddit automation.

Instead of paying for one, I started thinking about the specific problem I wanted to solve.

Could I build it myself?

So I tried.

I gave Claude the context.

I explained the workflow.

I shared screenshots.

I showed examples.

I explained what I wanted the application to do.

And I started small.

One piece at a time.

Then I tested it.

Added something.

Removed something.

Changed the flow.

Found something that didn't make sense.

Fixed it.

AI would sometimes suggest features I hadn't even thought about.

Sometimes I would use them.

Sometimes I would say, “No, that's unnecessary.”

And that's important too.

Because AI isn't deciding what the product should be.

I'm deciding what the product should achieve.

AI is helping me get there.

Eventually, I had a fully functional web application.

My first one.

That was a very different feeling from getting an HTML page to open in a browser.

Then I decided to put it in the real world

Getting something to work on your laptop is satisfying.

Getting someone else to use it is a completely different feeling.

So I deployed it.

AWS became part of the journey.

I used serverless services such as Lambda and DynamoDB, along with the other components needed to make the application work.

And the best part?

It costs me close to nothing.

Not because cloud infrastructure is free.

But because the usage of the services I'm using fits within their available free usage for what I currently need.

That was the moment I really understood the difference between building something and shipping something.

I had gone from:

HTML → frontend → backend → database → localhost → cloud → production.

And somewhere in that progression, I stopped thinking:

“Can I build this?”

and started thinking:

“How should I build this?”

That is a pretty significant change for a non-engineer.

AI isn't doing everything for me

This is also where I think some of the conversation around AI gets oversimplified.

No, I don't just type:

“Build me an app.”

and come back ten minutes later to a production-ready SaaS business.

If only.

Building with AI still requires judgment.

You need to know what problem you're solving.

You need to provide context.

You need to test what you get.

You need to recognize when something doesn't make sense.

You need to make decisions about features.

You need to understand enough of the code to know what you're changing.

You need to think about security.

And you need to keep refining the product.

Sometimes AI gets it completely right.

Sometimes it gives me something I would never have thought of.

Sometimes it confidently gives me something that makes absolutely no sense.

And sometimes I spend 45 minutes debugging something that ultimately turns out to be a typo.

That is software development, I suppose.

Just with a very patient colleague sitting beside me.

My social media feed has become my unofficial engineering curriculum

My social media feed is now full of people talking about GitHub repositories, AI models, frameworks, tools, open-source projects, agents, APIs and things I didn't know existed.

The algorithm has clearly decided that I am now a technical person.

I'm not sure when that happened.

But I am enjoying it.

Earlier, if I didn't know that a particular tool or project existed, I had no way of considering it.

Now, I discover something and immediately ask:

Could this solve my problem?

That question alone has expanded what I think is possible.

I don't need to build every component.

I can discover what already exists, understand it, adapt it and connect it to what I'm building.

The internet gave us open source.

AI is making open source much more accessible to people who wouldn't traditionally have known how to use it.

At least that's been my experience.

The checklist I didn't know I was creating

Looking back, my journey almost has a timeline.

2024 — Frontend. Done.

I could build interfaces.

2025 — Backend integration. Done.

I could connect the interface to actual functionality.

2026 — Cloud and productionization. Done.

I could take what I built locally and deploy it into the cloud.

Security is part of this journey too, although I wouldn't put a big green tick next to that one yet.

That's still very much a work in progress.

Because there is a big difference between:

“It works.”

and

“It works securely, reliably and properly in production.”

I'm learning the second one now.

So, what happens when a non-engineer starts building and shipping with AI?

You become much less intimidated by technology.

That's probably the simplest answer.

You stop seeing software as this enormous thing that only engineers are allowed to touch.

You start seeing it as a collection of problems.

Frontend problem?

Let's figure it out.

Backend problem?

Let's figure it out.

Need a database?

Let's figure it out.

Need an open-source tool?

Let's find one.

Need to deploy it?

Let's learn how.

Need to fix something in production?

Well...

Let's definitely figure that one out before anyone notices.

And that mindset shift is probably more valuable to me than learning any individual framework.

AI hasn't made me an engineer.

It has made me capable of building things I previously couldn't build.

And cloud has made me capable of taking those things beyond my laptop.

That's the part I find exciting.

Because today, almost anyone can ask AI to generate a website.

The interesting question is what you do after it generates the first version.

Do you know what problem you're solving?

Can you make the product better?

Can you connect the pieces?

Can you use what already exists?

Can you test it?

Can you secure it?

Can you deploy it?

Can you keep improving it?

That's the journey I'm on.

What's next?

Apparently, I haven't learned my lesson.

I've checked web applications off my personal list.

So the next one is a fully functional mobile or tablet application.

I don't know exactly how that journey will go.

I'm sure I'll break things.

I'm sure I'll encounter technologies I've never heard of.

I'm sure I'll ask AI questions that make me sound considerably more technical than I actually am.

But I'm also fairly sure I'll figure it out.

Because that is perhaps the biggest thing that has changed.

A few years ago, I would have looked at a software product and thought:

“I wish I could build that.”

Today, I look at one and think:

“Interesting. I wonder how I would build that.”

For a non-engineer, that's a pretty big shift.

I didn't become an engineer.

I became a builder.

And now I'm learning how to ship.