The method
A practical way to stop collecting ideas and start owning projects.
Self-freelancing means using your freelancer skills for a client you control: you. You still research, scope, build, test, and deliver. The difference is that the thing you deliver belongs to you when the invoice would normally end.
Why this matters now
The default freelancer path keeps paying you to make other people’s assets better.
There is nothing wrong with client work. It paid my bills and taught me a lot. But it is easy to stay in the loop: sell time, finish the job, start over. The better move is to reserve a small part of your work week for projects that can keep helping people after the first build is done.
- 01
Find a real problem
Look for a YouTube video where somebody is explaining a frustrating job, workaround, or gap. Do not hunt for a billion-dollar idea. Hunt for a repeated annoyance.
- 02
Get the language
Drop the video into YouTube to Transcript. Read the transcript like a client brief: what is the person trying to do, what keeps getting in the way, and what words do they use when they describe it?
- 03
Make Codex useful
Give Codex the transcript and ask it to identify the user, problem, smallest useful product, pages, and first build scope. Keep it narrow enough that you can publish instead of admire the plan.
- 04
Start from an Astro theme
Use an Astro theme for the boring foundation: layout, responsive styling, blog plumbing, and deploy-ready structure. Change the parts that matter. Do not build a design system because you are avoiding the project.
- 05
Ship and learn
Publish the first working version. Then put it in front of the people who already cared enough to watch or make the original video. Their response tells you what to build next.
The parts people get stuck on
“I do not have time.”
Then do not start a company. Give one small build a fixed block on your calendar and make the first version ugly but real. Client work will expand forever if you let it.
“I cannot code.”
You do not need to become a full-time developer. Codex can turn a clear, narrow brief into working implementation. Your job is still to make decisions, test the result, and stay close to the actual problem.
“What if the idea is bad?”
That is why the first version should be small. A bad small project is useful research. A big unshipped project is just expensive avoidance.
This is not a course or a promise. It is the way I am working now.
I will share the builds, the prompts that helped, what broke, and what I would do differently. Start with the first field note.
Turn a transcript into a project →