DEV Community: Marcus Kim

Freelancing Got Easier When I Stopped Carrying the Whole Project in My Head

Marcus Kim — Mon, 15 Jun 2026 23:07:01 +0000

When people imagine freelancing, they usually picture freedom.

Flexible schedule. Working for yourself. Laptop life. Coffee shop mythologies. The usual propaganda.

What they do not picture is the mental load.

That was one of the first things that hit me once I started doing real freelance work.

The coding matters, obviously. But the part that wears you down is not always the code itself.

It is trying to hold the entire project in your head at once.

What did I finish last time?

What broke when I changed that screen?

What does the client still need to see?

Which feature is actually next?

What did we agree on originally?

What was part of scope, and what quietly wandered in through the side door wearing a fake mustache?

That is the kind of stuff that makes a project feel heavier than it technically is.

I am finishing my first major freelance app project right now, and one of the biggest lessons has been that freelancing is not just about doing the work.

It is about building a work system that lets you keep doing the work without turning your own brain into a junk drawer.

That sounds less glamorous than "be your own boss," but it is much more useful.

My early mistake was treating memory like infrastructure

When I first started freelancing, I approached project management in a pretty primitive way.

Part of it was a normal beginner mistake. Part of it was me being optimistic in a slightly stupid way.

I thought if I stayed close enough to the project, I could just remember everything.

The next tasks.

The open bugs.

The half-finished screens.

The client expectations.

The tool setup.

The design details.

The new requests.

The "I will fix that later" list that somehow grows like mold in a damp apartment.

That works for about eleven minutes.

After that, your attention starts leaking all over the floor.

The problem is not that you forget everything.

The problem is that you spend too much energy reloading context.

And context reload is sneaky because it feels like work.

You open files. You scan notes. You click around the app. You reread messages. You try to reconstruct what Past You meant by some vague task like "clean up event flow maybe."

You are technically busy.

But you are not moving.

That is one of the least fun forms of fake productivity.

Freelancing is systems design in disguise

The more I do this, the less I think freelancing is mainly about technical skill.

Technical skill matters. You still have to build the thing.

But day to day, freelancing feels more like systems design.

You are designing:

how you pick the next task
how you preserve project context
how you communicate progress
how you protect the timeline
how you prevent scope from mutating into a swamp creature
how you keep enough momentum to finish

That is true even if you are a team of one.

Especially if you are a team of one.

In my current project, I am handling development, debugging, design coordination, backend management, and client execution. I am using Codex heavily, along with tools like Firebase, Figma, and Xcode.

That setup can be powerful, but only if there is some operating structure around it.

Without a system, AI does not save you from chaos.

It can actually help you produce chaos faster.

That has become one of my strongest beliefs about AI in work generally.

AI is leverage, not order.

If you already have a decent working system, AI can multiply it.

If your workflow is messy, AI can multiply the mess with shocking efficiency.

The biggest upgrade was offloading project memory on purpose

One of the most useful shifts in my workflow was simple:

I stopped expecting myself to carry the whole project mentally.

Earlier on, I used todo lists that Cursor and I would both update and manage. That was better than nothing, but it still depended a lot on me manually holding the thread together.

Now I lean on Codex much more directly for project continuity.

I can sit down, ask where the project left off, see what remains, and pick up the next concrete task instead of rebuilding the whole mental map from scratch.

That matters more than it sounds like it should.

Because when the startup cost of beginning work is lower, you work more.

You hesitate less.

You waste less momentum.

You spend less time doing archaeological fieldwork on your own half-finished app.

I think a lot of people underestimate this part.

They think AI helps because it writes code faster.

That is true, but for me one of the bigger wins is that it helps me preserve and reload context faster.

That is operational leverage.

And operational leverage is what makes consistent output possible.

Meaningful updates beat constant updates

Another thing I had to learn is that communication gets easier when the work is organized around demonstrable progress.

My client communication is intentionally sparse, but meaningful.

We do webcam meetings every so often, and the conversations work best when I have something real to show.

Not a vague status report.

Not a pile of effort.

Not "I was super busy this week."

Something concrete.

A feature that works.

A workflow that completes.

A screen that now behaves correctly.

A user action that was impossible before and is possible now.

That changed how I think about task breakdown.

Instead of trying to move ten pieces at once, I try to complete one use case at a time.

That way each demo answers a simple question:

What can the user do now that they could not do before?

That is a much cleaner unit of progress.

It also reduces my own stress, because "finish one use case" is easier to manage than "make the project generally better."

The second one sounds ambitious.

It is also a good way to drift for six hours and emerge holding three bugs and a broken layout.

Scope creep is not just a client problem

Freelancers love complaining about scope creep, and sometimes that is justified.

Clients really do ask for new features like they are adding fries to an order.

But scope creep is not only a client behavior problem.

It is also a system weakness problem.

If the project does not have clear boundaries, every new idea gets treated like a small adjustment instead of what it often is: new work with new timeline consequences.

I learned this the hard way.

Accepting additional features after the original contract can seriously affect deadlines. Once that starts happening, you either extend the timeline realistically or you pretend time is fake and suffer accordingly.

I recommend the first option.

A lot of freelance pain comes from trying to preserve the fantasy that the original schedule still makes sense after the project changed shape.

It usually does not.

This is another reason systems matter.

A decent system makes scope visible.

It records what was agreed on.

It makes it easier to say, "Yes, that can be added, but it affects timeline and milestones."

That is not being difficult.

That is protecting the project from becoming a wish fountain.

My work got better when I designed the environment, not just the task list

One of the more boring lessons that turned out to be true is that productivity depends a lot on environment.

Not just physical environment, although that matters.

I mean the whole working setup.

How easily can I start?

How quickly can I figure out what is next?

How much friction is there between intention and execution?

Do I have a clean loop for work, QA, and breaks?

Am I building according to spec, or am I improvising a loose scaffold and planning to make it pretty later?

Because that "later" phase is often where the pain begins.

One lesson I really wish I had internalized earlier is to build the UI according to spec first instead of loosely scaffolding and trying to retrofit the real interface afterward.

Redoing views often spills into functionality. Then what looked like a visual cleanup turns into deeper rework.

That is the sort of thing that makes a week disappear.

So now I care a lot more about setting the environment up correctly before I get too far into implementation.

That includes using AI well.

Not as a slot machine for random code output.

As a teammate inside a controlled process.

The practical rule I keep coming back to

If I had to compress this lesson into one line, it would be this:

Do not build a freelance workflow that depends on you feeling perfectly mentally organized every day.

That person does not exist.

At least not consistently enough to run a real business on.

Build a system that catches you when your brain is noisy.

Use tools that preserve context.

Break work into demoable units.

Make scope visible.

Protect your timeline.

Reduce startup friction.

Treat AI as leverage inside a process, not as a replacement for one.

That is the shift that made freelancing feel more real to me.

Less like improvisation.

Less like carrying a piano up a staircase by myself.

More like actually operating.

If you are freelancing now, or trying to start, the practical takeaway is simple:

Stop asking whether you can handle more in your head.

Start building a workflow that does not require you to.

That is usually where the real productivity begins.

I wrote AI App Builder From Zero for beginners who want to build their first app with an AI coding tool open beside them, but honestly, the same rule applies to freelance work too: clear systems beat heroic improvisation.

If you want a practical place to start, I made AI App Builder Starter Prompts: 24 free prompts for turning a rough app idea into a scoped first build.

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

Your First App Idea Is Hiding in a Group You Already Belong To

Marcus Kim — Mon, 15 Jun 2026 23:06:17 +0000

The worst place to look for your first app idea is nowhere.

That sounds obvious, but it is what a lot of people do.

They sit down, open a notebook, stare into the middle distance, and ask:

"What app should I build?"

That question is enormous.

It is too big. It has no walls. It gives your brain nothing to grab. It is like asking, "What should I do with my life?" while standing in front of a vending machine.

No wonder people freeze.

Then they do the next predictable thing. They start thinking in giant categories.

Productivity app.

Social app.

Fitness app.

AI app.

Marketplace.

Habit tracker.

Budgeting tool.

Those are not bad categories. But they are too abstract to build from. They sound like app-store shelves, not real human pain.

If you are a beginner trying to build your first app with AI, you do not need a vague category.

You need a person.

You need a problem.

You need a situation you understand well enough to notice what is annoying, inefficient, awkward, confusing, or unnecessarily painful.

That is why I think your first app idea is probably hiding inside a group you already belong to.

Start with your groups

Before you ask AI to help you brainstorm an app, make an inventory of your own life.

Not your resume.

Your groups.

The worlds you already live in.

That might include:

hobbies
profession
education
school or institution
culture
religion or community
age group
local area
family situation
health situation
fandoms
subcultures
tools you use every week
weird little workflows you have accepted as normal

This matters because app ideas rarely appear as fully formed lightning bolts.

Usually they start as friction.

Something takes too many steps.

Something is awkward on a phone.

Something works, but only if you use three separate tools and quietly suffer.

Something is built for professionals when you need the lightweight version.

Something is built for beginners when you need just a little more power.

Something almost solves the problem, but misses the way your group actually behaves.

That last one is where interesting products live.

The goal is not to ask, "What app could everyone use?"

The better question is:

"What group do I understand better than a random person, and what problem do people in that group keep working around?"

That is a much better starting point.

My musician problem

I have been a hobbyist musician since my teens, but I started taking it more seriously in my early twenties.

I played in a few bands while getting my undergraduate degree in entrepreneurship in Boise. I kept practicing. I got better slowly. I learned enough piano, drums, guitar, vocals, and now bass to write songs that make sense.

I am not claiming to be a master of every instrument.

But I can write songs.

I can make an album.

I released one in 2026 under my project, Task Manager Not Responding. The first album is lo-fi pop-punk in the spirit of early Blink-182. The next one I am working on is more southern hardcore, influenced by Maylene and the Sons of Disaster.

I record everything at home with my own equipment.

That means I have lived inside a very specific problem:

Recording quick musical ideas on a phone is still annoying.

The serious way to record music is an audio interface and a DAW.

DAW means digital audio workstation. Think Logic Pro, Ableton, that kind of software.

That setup is powerful. It is also heavier than what I need when I just want to catch a riff before it escapes into the fog.

On the other end, there is Voice Memos.

Voice Memos is fast, which is great. But it is not really a musician tool. I want a built-in metronome. I want one-tap file creation. I want one-tap recording. I want exports that work cleanly with proper music software. I want a workflow that respects the fact that the thing I am recording might be guitar, vocals, drums, a melody, or a rough arrangement idea.

Then there is GarageBand on iPhone.

GarageBand is powerful, but on mobile it feels too fiddly for this use case. Too many features mashed into too many menus and submenus. It can do a lot, but sometimes I do not want a mobile studio.

I want a musical scratchpad with a metronome and clean export.

That is an app idea.

Not because I sat down and asked, "What is a hot market?"

Because I am a musician who keeps feeling the same product gap.

The best ideas often live between tools

A lot of useful app ideas live between two tools that almost work.

For me:

Voice Memos is too simple.

GarageBand is too heavy.

The gap is a simple musician-first recording app.

That is a useful pattern.

You can ask:

What tool is too complicated for the quick version of the job?

What tool is too simple for the real version of the job?

What does my group actually need between those two?

That is how you stop building vague apps and start building precise utilities.

And I like simple utility apps.

If I could make every app the way I want, it would have beautiful UI, be colorful, be playful, still be stately enough to take seriously, and actually function. Not decorative nonsense. Not enterprise-gray sadness. Useful first, memorable second, polished throughout.

That is the kind of product taste that comes from living with tools, not reading a trend report.

Intersections make ideas sharper

One group can give you a market.

Two or three groups can give you a sharper idea.

Musician is a group.

College student is a group.

Sports fan is a group.

Each one can produce ideas:

A better metronome app for musicians.

A textbook scanner and summarizer for students.

A sports research app for sports fans.

But now combine them.

What about music majors?

Maybe they need a sheet-music scanner that plays the scanned music back so they can study faster.

What about college sports fans?

Maybe they need a sports research tool focused specifically on collegiate sports, with responsible-use boundaries if betting is involved.

What about college band conductors?

Maybe they need an iPad app for game-day band rosters, practice coordination, football-game reminders, and band-member chat.

The intersection makes the idea less generic.

"Productivity app" is mush.

"Roster and coordination app for college marching band game days" is something you can actually picture.

That matters because AI coding tools are much better when the product shape is specific.

If you say:

"Build me a productivity app."

You are handing AI a fog machine.

If you say:

"Help me design version one of an iPad app for college band conductors to manage game-day roster attendance, send practice updates, and keep the next football-game schedule visible."

Now there is a person.

There is a workflow.

There is a setting.

There is a first version.

There is something to build.

Your lived experience is market research

A lot of beginners discount their own experience because it feels too ordinary.

They think an app idea has to come from some grand strategic insight.

Sometimes it does.

But a lot of good software comes from noticing that a specific group has a specific problem and the current workaround is ugly.

That is market research too.

Not complete market research. You still have to validate. You still have to talk to people. You still have to check whether the problem is real outside your own head.

But your own irritation is a starting sensor.

It tells you where to look.

I belong to a lot of groups that could generate app ideas.

Musicians. Guitarists. Drummers. Singers. Recording artists. Software engineers. Freelancers. Magic: The Gathering players. Comic readers. Self-improvement people. Indie app builders. Working professionals. People in their thirties. People who have been through the "how do I get experience without a job and a job without experience" loop.

Each group has problems.

Musicians have phone-recording friction.

AI builders need to learn how to wrangle coding tools without turning their apps into chaos.

Freelancers need better project-management philosophy, not just another task list.

College graduates have the first-job paradox.

iOS developers may realize too late that launching iOS-first can create painful Android rewrite decisions later.

Those are not random ideas.

They come from living near the problem.

AI can interview you into an idea

This is where AI becomes genuinely useful.

Do not ask:

"Give me app ideas."

That usually produces a list that sounds like it came from a startup name generator that got trapped in an airport business lounge.

Ask it to interview you.

Use something like this:

Interview me about the groups I belong to: hobbies, profession, education, communities, tools I use, and problems I notice. Then generate app or website ideas from problems inside those groups. For each idea, name the user, problem, current workaround, version-one workflow, and why I might understand this market better than a random builder.

That prompt does something important.

It forces the AI to start from your context.

Not general app categories.

Your groups.

Your frictions.

Your unfair familiarity.

Then you can go one layer deeper:

Take my identity inventory and combine groups into intersection ideas. For each idea, give me the target user, pain, existing workaround, version-one workflow, why the intersection matters, platform recommendation, and smallest useful first version. Avoid giant platforms. Favor apps and websites I can test with real people.

That is much better than asking for genius.

You are asking for structure.

The first version should be boringly clear

Once you have an idea, shrink it.

This is where beginners go wrong.

They find one good problem, then immediately add accounts, social features, analytics, recommendations, subscriptions, chat, notifications, admin dashboards, export settings, teams, payments, and a mascot they will regret later.

Do not do that.

For the musician recording app, version one might be:

Open app.

Choose tempo or start without one.

Tap record.

Capture audio.

Name the take.

Add quick notes.

Export the file.

That is enough to test whether the core idea has legs.

No social network for musicians.

No AI mastering.

No marketplace for session players.

No "community layer."

No full DAW.

Just the core workflow.

If that workflow is useful, you earned the next feature.

If it is not useful, the extra features were just decorations on top of a weak foundation.

Good software still needs value

This is one of the biggest lessons I keep relearning in software and freelancing.

Being good at the work is not enough.

Good process is not enough.

Clean code is not enough.

Beautiful UI is not enough.

An app has to deliver value.

You can build a perfectly engineered app that tells users exactly how to open a Starbucks on an asteroid.

The architecture might be beautiful.

The buttons might be tasteful.

The tests might pass.

The deployment might be flawless.

But the value is limited, at least for now.

That is the point.

Software quality matters. I care about it a lot. But quality only matters after the problem matters.

Your first job is not to invent an impressive app category.

Your first job is to find a real human workflow worth improving.

The easiest place to look is inside the groups you already understand.

Final thought

Your first app idea does not need to fall from the sky.

It can come from your practice room.

Your client work.

Your hobby.

Your school.

Your job search.

Your weekly annoyance.

Your group chat.

Your weird little workaround.

Start there.

Inventory your groups.

Find the friction.

Combine identities until the problem gets sharper.

Then use AI to turn that problem into a version-one workflow.

Do not build for everyone.

Build for a person you can picture.

That is where the app starts becoming real.

If you want a practical place to start, I made AI App Builder Starter Prompts: 24 free prompts for turning a rough app idea into a scoped first build.

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

If You Skip the Map, AI Builds You a Maze

Marcus Kim — Mon, 15 Jun 2026 22:59:05 +0000

You can build software faster than ever now.

That is the good news.

The bad news is that you can also build yourself into a disaster faster than ever now.

I see beginners open an AI coding tool, type something like "help me build my app," and then act surprised when the result looks like a confused intern got locked in a supply closet with a keyboard and three energy drinks.

The code exists.

The app technically does things.

But the product is crooked.

The screens do not line up with the real workflow. The data model is half imagined. The features multiply like rabbits. Nothing is tested properly. Every new fix creates a new bug somewhere else. By the time the person notices what happened, they do not have an app. They have a maze.

This is not really an AI coding tool problem.

It is a mapping problem.

One of the biggest shifts AI coding tools create is that code is no longer the main bottleneck for beginners. The bottleneck moves upward. Now the hard part is defining the system clearly enough that the tool can build the right thing instead of a very fast wrong thing.

That sounds less exciting than "AI builds apps for anyone now," but it is the more useful truth.

I use AI coding tools heavily in real work, and the more I use them, the less I think of them as magic code machines.

I think of it more like a very capable builder that still needs a foreman, a blueprint, a materials list, and somebody on site who notices when the bathroom somehow ended up in the kitchen.

That is why I keep coming back to the same operating rule:

Build the map before you build the app.

That sounds obvious until you watch how people actually use these tools.

Most beginners try to jump straight from idea to implementation.

"Build me an app for restaurant bookings."

"Make me a dashboard for my business."

"Create a mobile app for dog walkers."

That is not a software request. That is a business wish wearing a hoodie.

An AI coding tool can help turn it into something real, but only if you give it enough structure to work with.

When I was learning software, that missing structure used to show up later in the process. You would spend hours digging through old Stack Overflow answers, partial tutorials, and documentation archaeology before discovering you did not actually understand the system you were trying to build.

AI compresses that loop.

Now you can generate code immediately, which feels great right up until you realize you generated confusion at high speed.

That is why judgment matters more, not less.

My software background helped me see this more clearly over time. I came into software through a master's program in software engineering, and one of the most useful things it gave me was not just coding practice. It gave me a view of software as process, architecture, verification, maintenance, and tradeoffs.

That matters because beginners usually think software equals code.

It does not.

Software is also:

what the app is supposed to do
what it should not do yet
how data moves through the system
what the first user workflow actually is
what success looks like
what must be tested before you call something finished

If you skip those questions, your AI coding tool will still try to help you. That is the tricky part.

AI rarely says, "This request is too vague, and you are about to waste three days."

It usually says, "Absolutely," and starts producing files.

That is why the beginner mistake is not lack of effort. It is misplaced effort.

People think the work starts when the files start appearing.

Usually the real work starts before that.

On client projects, this becomes painfully obvious.

I am finishing my first major freelance project right now, and one of the biggest lessons has been that building the software is only one slice of the actual job. I have had to manage scope, architecture, backend assumptions, debugging, design handoff, tool coordination, and client clarity, often while being the only person on the project.

That changes how you use AI.

You stop asking for random code chunks and start building a working system around the tool.

You create shared project knowledge.

You define the stack.

You describe the workflows.

You set rules for what "done" means.

You tell your AI coding tool what to verify.

You give it enough context that it can behave more like a teammate and less like a slot machine.

This is the middle ground that a lot of beginners miss.

They think they have two options:

Ask for one tiny tweak like moving a button six pixels.
Ask for a billion-dollar platform by Friday.

There is a much better middle.

Ask your AI coding tool to help you define version one.

Ask it to propose the smallest useful workflow.

Ask it what data model the app needs before building UI.

Ask it what edge cases should be tested before launch.

Ask it what assumptions are still fuzzy.

Ask it to turn your vague idea into a scoped plan with success criteria.

That is where the leverage starts.

Let me make this concrete.

If you want to build a simple booking app, do not start with "build me the app."

Start with something more like this:

"Help me define the version one workflow for a booking app. The user should be able to view available appointment times, pick one, enter their contact info, and receive confirmation. Admins should be able to set availability manually. No payments yet. No team accounts yet. No SMS yet. Show me the required data model, screens, and QA checklist before we write code."

That single shift changes everything.

Now the AI has boundaries.

Now you have a product shape.

Now you can inspect whether the architecture matches the workflow.

Now you can catch overbuilding early.

Now "done" means something.

This is also why I tell beginners not to romanticize chaos.

People love the fantasy that great software is built in some cinematic blur of energy drinks, half-broken prompts, random feature ideas, and heroic all-nighters.

In reality, chaos mostly creates rework.

The better your environment and source of truth, the better your AI outputs get.

The better your rules, the better your iterations get.

The better your QA expectations, the less fake progress you confuse for real progress.

This is especially important because AI makes it easier to get seduced by visible output.

A new screen appears.

A component renders.

A route works.

A button submits.

That feels like progress.

Sometimes it is.

Sometimes it is just a prettier version of the wrong app.

That is where architecture and QA stop sounding boring and start sounding like self-defense.

Architecture is just the decision-making layer that prevents your app from turning into a pile of disconnected conveniences.

QA is just the habit of proving the thing works the way you think it works.

Neither one is optional if you want to build software that survives contact with reality.

And this is where I think AI coding tools are genuinely exciting for beginners.

Not because they eliminate the need to think.

Because they make good thinking more valuable.

You do not need to know everything before you start.

You do not need to become a senior engineer before opening an AI coding tool.

But you do need to learn how to guide the system:

define the problem clearly
shrink version one aggressively
create shared project knowledge
set success criteria
ask for verification, not just generation

That is a learnable skill.

Honestly, it is one of the main skills that matters now.

The future of software is moving closer to English-to-machine execution. I believe that. AI is a landmark shift.

But if more people are going to build software this way, then more people need to understand that prompting is not the whole craft.

Direction is part of the craft.

Scope is part of the craft.

Testing is part of the craft.

Restraint is part of the craft.

If you skip the map, the tool will happily help you build a maze.

If you build the map first, the tool becomes much more powerful.

That is the real beginner advantage.

You do not need to pretend to be an expert.

You need to become a clear director.

That is a much more reachable job.

And it is the one that actually gets apps finished.

If you are new to this, the practical takeaway is simple: before you ask your AI coding tool to build, ask it to define.

Have it help you shape version one, name the assumptions, outline the architecture, and draft a QA checklist.

Then build.

That order saves a ridiculous amount of pain.

I wrote AI App Builder From Zero for beginners who want to build their first app with an AI coding tool open beside them.

If you want a practical place to start, I made AI App Builder Starter Prompts: 24 free prompts for turning a rough app idea into a scoped first build.

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

I Didn't Enter Software Through the Clean Front Door

Marcus Kim — Mon, 15 Jun 2026 19:45:20 +0000

I did not enter software through the clean front door.

I did not grow up as the kid who was building compilers in middle school, casually reading operating systems books for fun, and saying things like "I just love elegant abstractions" while everyone else was trying to survive algebra.

My path was messier than that.

I did not have a computer science undergraduate degree. I did not have the standard foundation. I did not arrive in software with the quiet confidence of someone who had been speaking the language since childhood.

I got into software by deciding I wanted a master's degree in software engineering, then realizing I had to piece together the prerequisite foundation first.

So that is what I did.

I took C. I took C++. I took data structures. I took some Java. I took web development. Not as part of some neat, coherent undergraduate computer science path, but as loose prerequisite work so I could qualify for the program I wanted to enter.

It was not glamorous.

It was a lot of grinding through unfamiliar concepts, staring at errors, re-reading examples, and slowly building the mental shelf space required to understand what software even is.

There was a lot of elbow grease involved.

Enough elbow grease that, if software had not worked out, I probably could have walked into a mechanic shop and started lubricating engine parts through sheer academic residue.

But it worked.

I got through the prerequisites. Then I went through the software engineering master's program at California State University, Fullerton. That program gave me a much broader view of software than just "write code until the computer stops yelling."

I studied software process, software architecture, software verification and validation, software measurement, maintenance, standards, management, and professional issues. The program ended with a capstone project where we had to build software and document the process like actual software engineers, not just people throwing code at a wall and hoping the wall had good taste.

That mattered.

Because one of the biggest mistakes beginners make with AI coding tools right now is thinking the code is the whole game.

It is not.

Code is part of the game. But software is also scope, architecture, data, user flows, testing, deployment, maintenance, tradeoffs, communication, and knowing what not to build yet.

That is the part beginners usually do not see.

And honestly, it is the part I did not fully see at first either.

After I graduated, I did not immediately stroll into a perfect software job. I graduated into the pandemic era and spent about a year unsuccessfully job searching. Then job searching moved to the back burner while I worked an unrelated customer service job.

That period was frustrating.

It is hard to explain the particular flavor of discouragement that comes from earning a software degree, doing the work, building the projects, learning the concepts, and then still feeling like the industry is standing behind a glass wall.

You can see the world you are trying to enter.

You just cannot seem to get through the door.

Eventually, a friend of a friend who worked at Uber helped mentor me through the job search process. Around that same period, ChatGPT showed up, and that changed the way I worked.

Before AI, my programming process looked like the standard developer scavenger hunt.

Search Google.

Open Stack Overflow.

Find a six-year-old answer.

Realize the library changed.

Open documentation.

Find a YouTube tutorial.

Hope the tutorial is not using a deprecated version.

Copy one piece.

Modify another piece.

Read a forum thread from 2014.

Stitch together five partial answers until the thing finally works.

That was normal.

Developers pretend this was noble, but a lot of it was just inefficient archaeology.

AI compressed that loop.

It did not magically make me good at everything. That is not how this works. But it gave me a way to ask better questions faster. It let me compare options, debug errors, explain unfamiliar concepts, rewrite plans, and move through confusion with less dead time.

So I used it.

I built my portfolio. I applied heavily. I started programming in public. I made a 90-video series of myself building a SpriteKit 2D iOS game.

That public work mattered because it turned me from a resume into a person with visible proof of effort.

Eventually, after a long stretch of pushing, I started getting interviews. Then something unexpected happened.

A couple of startup founders found me on LinkedIn. They liked what I had to say about how I would build their product. They hired me, and I built the first version of their event-based social media app.

That project became a serious step forward for me.

The first version was good enough that they gave me equity and brought in two junior iOS developers under me. I ended up managing the iOS side of the project for about five months.

That was the moment where software stopped being only academic for me.

It became product work.

Real scope. Real tradeoffs. Real people. Real ambiguity. Real pressure.

And later, freelancing made that even more obvious.

When you are the only person responsible for a client project, you learn very quickly that "I can write code" is not enough. You have to understand the app as a system. You have to manage the client relationship. You have to make architecture decisions. You have to use design tools. You have to manage backend assumptions. You have to test. You have to explain tradeoffs. You have to keep the whole thing moving even when the path is not perfectly clear.

That is where AI tools became more than a novelty for me.

I started using Cursor, Figma, Codex, backend tools, browser automation, and AI planning workflows as part of the actual work.

Not as toys.

As leverage.

And that is why I care so much about beginners using AI coding tools well.

Because I know what it feels like to start outside the software world and try to build your way in. I know what it feels like to lack the map. I know what it feels like to ask basic questions and worry that the basic question means you do not belong.

But I also know something else now.

Software is becoming more accessible.

Not easy. Accessible.

That distinction matters.

AI does not remove the need for judgment. It does not remove the need for taste, persistence, testing, product thinking, or architecture. If anything, it makes those things more important, because now beginners can generate much more software much faster.

That is powerful.

It is also dangerous if you have no idea what you are asking for.

A beginner with an AI coding tool should not start by saying, "Build me an app."

That is too vague.

Start by building the map.

What is the app for?

Who uses it?

What is the first workflow?

What should version one not include?

What data exists?

What tools are involved?

What does success look like?

What should your AI coding tool verify before it says the task is done?

That is the real work.

The beginner's job is not to become a senior engineer overnight. The beginner's job is to learn how to direct the tool without letting the tool shape the product by accident.

That is why I wrote AI App Builder From Zero.

I wrote it for people who never thought software was accessible to them. People with app ideas. People with small business problems. People who want to build something useful but do not know what a stack is, what a repo is, what a backend does, or what to type into the chatbox after opening an AI coding tool for the first time.

The internet has plenty of information.

Too much, honestly.

Reddit threads. YouTube tutorials. X posts. Documentation. Hot takes. Tool comparisons. Prompt lists. Arguments about frameworks. People confidently disagreeing with each other in public.

That can be useful once you have a map.

But if you are brand new, it can feel like trying to drink from a fire hose while someone keeps changing the hose into a different hose.

Beginners do not need more noise.

They need a first snowball.

Something small enough to pick up, concrete enough to push, and useful enough to gather momentum.

That is how I think about learning software with AI.

You do not need to know everything before you begin.

You do need a working model of what you are doing.

You need shared project knowledge. You need definitions. You need scope. You need rules. You need a way to ask Codex to plan, build, test, review, and stop.

That is the difference between using AI as a magic slot machine and using AI as a working partner.

My path into software was not clean.

That is probably why I am interested in teaching this.

I do not think the next generation of builders will all come from traditional computer science paths. Some will. Many will not.

Some will come from business.

Some will come from design.

Some will come from operations.

Some will come from customer service jobs, weird side projects, unfinished app ideas, freelance experiments, and late-night conversations with AI tools.

That is good.

Software should have more doors.

AI is opening some of them.

But walking through still requires discipline.

Learn the tool.

Build the map.

Control the scope.

Test the work.

Keep going.

That is the path.

It may not be the clean front door.

But it is a door.

And for a lot of people, that is enough to start.

If you want a practical place to start, I made AI App Builder Starter Prompts: 24 free prompts for turning a rough app idea into a scoped first build.

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts