Eight days of homepage revisions, repeated mistakes, a $100 subscription that wasn't enough, and the workflow that helped me finally launch.
1. I Don't Know How to Code. I Still Wanted to Build a SaaS.
I don't have a traditional programming background.
I can't write a complete web application from scratch. I don't fully understand every piece of code that an AI coding assistant generates, and when something breaks, I can't always identify the cause immediately.
But I wanted to build an AI video creation platform.
I had ideas about the interface, the user experience, and the kind of creative tools I wanted to offer. What I didn't have was the technical ability to implement everything myself.
So I decided to use OpenAI Codex.
Eight days later, I launched Kling40.app, an independent AI video SaaS project.
The website is live, with a video generator interface and video examples. I'm still improving the prompt library and refining the overall experience.
But here's the part that surprised me:
I spent most of those eight days repeatedly changing the homepage.
Not building dozens of advanced features. Not developing a revolutionary AI model.
Just trying to make the website look and work the way I wanted.
That experience changed how I think about AI-assisted development.
2. Eight Days of Homepage Revisions
When I started, I thought building a homepage would be relatively simple.
I wanted a clean AI video generator, cinematic examples, and a modern interface that users could understand immediately.
Codex could generate and modify the code.
But the result often didn't match what I had imagined.
Sometimes the layout felt wrong. Sometimes the visual design looked ordinary. Other times, a change introduced new problems, and I had to ask Codex to redo the work.
The cycle became familiar:
- Describe what I wanted.
- Wait for Codex to make changes.
- Check the website.
- Discover that something wasn't right.
- Rewrite the instructions and try again.
I repeated this process throughout the eight days.
At first, I thought the problem was simply that Codex wasn't producing good enough results.
Eventually, I realized that my instructions were often too vague.
Asking an AI to "make the homepage more professional" leaves too many decisions undefined.
What does professional mean?
Better spacing? A different layout? Stronger typography? A more cinematic visual style? Fewer sections?
Without clear requirements, the coding assistant has to guess.
And when its guesses don't match your expectations, you pay for those mistakes with more iterations.
For a solo founder working with limited time and AI usage, that becomes expensive.
3. The Workflow That Made Codex More Useful
My biggest improvement wasn't switching models or buying a more expensive subscription.
It was changing how I worked.
Instead of asking Codex to figure out the product design and implement it at the same time, I started discussing the plan with ChatGPT first.
My workflow became:
Step 1 — Plan with ChatGPT
I explain what I want to build, compare different approaches, and discuss the design or functionality before touching the code.
Step 2 — Define the expected result
I try to make the requirements specific.
What should change? What should remain unchanged? What should the final interface look like?
Step 3 — Implement with Codex
Once the plan is clearer, I give Codex the implementation task.
Step 4 — Review the actual website
I check the result myself, identify problems, and decide whether another revision is necessary.
This doesn't eliminate mistakes.
ChatGPT can misunderstand requirements, and Codex can still introduce bugs.
But separating planning from implementation has made my workflow more manageable.
Here's an illustrative example of the kind of instruction I now aim for:
Keep the AI video generator visible near the top of the homepage. Place the video examples below it, maintain consistent spacing between sections, and avoid changing unrelated functionality. Before editing, identify which components need to change.
That's an example of my preferred instruction style, not a recovered transcript of an actual Codex conversation.
The difference is that the task has boundaries.
Instead of asking for something vaguely "better," I'm trying to describe a result that I can actually evaluate.
My most useful lesson: use AI to help clarify your requirements before asking another AI to implement them.
4. A Working Interface Isn't Necessarily a Good-Looking Interface
One thing I underestimated was how much attention visual design would require.
Codex could help build functional components, but a functioning page didn't automatically look polished.
I wanted Kling40.app to feel like a professional AI video product, not a collection of unrelated interface elements.
That meant paying attention to:
- Typography and visual hierarchy
- Consistent spacing
- How the generator appears on the first screen
- How video examples are displayed
- The relationship between images, text, and interactive controls
- Consistency across the homepage
I learned that visual quality needs to be part of the requirements from the beginning.
Otherwise, you can spend days rebuilding sections that technically work but don't look right.
I'm also interested in evaluating Claude for frontend design and visual refinement.
Codex was my main development tool for this project, so I haven't conducted a controlled comparison between the two.
I can't claim Claude always produces better interfaces.
But if I were starting another design-heavy project, I would seriously consider comparing their output on the same frontend task.
The important thing isn't which model has the strongest reputation.
It's which tool produces results that meet your requirements with the least unnecessary rework.
5. Codex Was Helpful, but Sometimes Painfully Slow
Another frustration was response speed.
During development, Codex sometimes became very slow.
That was especially frustrating because I was making repeated homepage revisions.
A small design change could require several interactions.
When each interaction takes too long, even simple work becomes exhausting.
On my Windows setup, I noticed a significant difference between the Codex extension in VS Code and the Codex command-line interface.
The VS Code extension sometimes took several minutes to respond, while the CLI often responded within seconds.
This was my personal experience, not a formal benchmark.
It doesn't mean the CLI is universally faster, or that the underlying AI model was responsible for the difference.
But it changed how I approached the problem.
Instead of assuming that Codex itself was always slow, I learned to consider the development interface and environment.
For a solo developer, response speed and reliability are part of the real cost of AI coding.
A powerful model isn't particularly helpful if your workflow keeps getting interrupted.
6. My $100 Codex Plan Lasted About Four Days of Intensive Work
I was using a $100-per-month subscription that included Codex.
During intensive development, I found that I could exhaust the weekly usage allowance in roughly four days.
That wasn't enough for the pace at which I wanted to work.
I still had changes to make, problems to fix, and parts of the website to improve.
But the available usage was limited.
This made me consider whether a more expensive subscription would be worthwhile.
OpenAI has offered higher-priced Pro tiers, including a $500-per-month option.
For a solo founder, $500 per month is a significant recurring expense.
That's $6,000 per year before paying for domains, hosting, databases, storage, or AI generation APIs.
I don't think the most expensive subscription is automatically the best choice.
If a developer consistently needs higher limits, upgrading may make sense.
But I wanted to understand whether I could first reduce unnecessary usage by improving my workflow.
Occasional Codex resets helped
I also followed public discussions from Tibo (@thsottiaux) about additional Codex usage resets.
Those occasional resets helped make my existing subscription more manageable.
But I don't treat them as guaranteed future capacity.
Promotional resets are not the same as unlimited usage, and future resets may not happen.
OpenAI also documents different reset mechanisms and usage conditions, which developers should check before making subscription decisions.
For me, the lesson was straightforward:
Before spending more money on AI coding, try to reduce the number of wasted iterations.
Better instructions won't solve every usage problem.
But repeatedly asking an AI to redo poorly defined tasks can consume a surprising amount of your available capacity.
And managing that cost matters when you're building a product independently.
7. I Launched the Website. That Doesn't Mean It's Successful Yet.
After eight days, Kling40.app was online.
The site has a video generator interface and video examples, while the prompt library is still being improved.
But I want to be realistic about the outcome.
The website hasn't achieved major results yet.
I don't have a story about thousands of paying customers or extraordinary revenue.
Right now, I'm still improving the product, learning about search visibility, and trying to understand what potential users actually need.
I also realized that launching a SaaS product involves much more than generating code.
You still need to decide:
- Which features are worth building
- How to make the interface understandable
- How to control operating costs
- How to communicate the product's value
- How to attract users
- How to know whether people actually find it useful
AI can help implement a feature.
It can't guarantee that the feature is worth building.
And a polished homepage doesn't automatically create a sustainable business.
I'm learning those lessons as I go.
8. What I'd Tell Someone Who Wants to Build with AI
If you're thinking about building a SaaS product without traditional programming skills, here are the lessons I'd share from my experience.
First, don't expect AI coding to eliminate mistakes.
You can still spend days fixing problems or repeating work.
Second, plan before implementation.
For me, discussing requirements with ChatGPT before giving tasks to Codex made the process more manageable.
Third, be specific about visual quality.
If design matters to your product, don't rely on vague instructions like "make it look modern."
Define what you actually want.
Fourth, consider the cost of wasted iterations.
A $100 subscription can feel expensive when the available usage disappears after a few days of intensive work.
Fifth, don't wait for everything to be perfect.
I spent eight days repeatedly improving the homepage.
At some point, I had to launch and start learning from the real world.
I'm still working on Kling40.app, improving the generator experience and expanding the prompt library.
I don't know how successful it will become.
But the experience has already changed my perspective on software development.
You don't necessarily need to know how to write code to start building a product. But you do need to learn how to define what you want, evaluate what AI produces, and make decisions when things go wrong.
That's the part AI hasn't replaced for me.
What About You?
I'm curious how other developers and indie founders approach AI-assisted development.
- Do you plan your features with ChatGPT before giving tasks to Codex?
- Have vague instructions caused you to redo large parts of a project?
- Is your AI coding subscription enough for a full week of intensive work?
- Have you found Claude or Codex better for frontend design?
I'd love to hear what has worked for you.
Top comments (0)