NOTE: The full detailed blog is https://medium.com/@clastron/how-i-built-a-1k-quality-landing-page-with-codex-and-a-few-tools-1ecb983f2dca - it details everything, the steps, failures, when, how, why, etc.
I started with a blank codebase.
About a week later, I had a fully implemented landing page with shaders, 3D models, custom interactions, responsive layouts, and mobile Lighthouse scores above 90 in three out of four categories.
I am not a web designer. I am a 15-year-old developer with no experience in web, UI, or UX design. No design degree, no agency background - just a simple teen boy who likes building things and had a clear idea of how the page should feel.
The stack was Vanilla JavaScript, Tailwind CSS, Codex, and a few useful tools. The only paid requirement was a $20 ChatGPT Plus plan. The design has now been ported into the real production system, with only the main marketing copy changing, although the page is not public yet.
The process was not one magical prompt:
Context → Plan → Mock up → Improve → Implement → Inspect → Test → Optimize
What I built, and the $1k claim
The page was for Promptyx, an AI prompt-management and engineering platform. It needed to feel simple, premium but affordable, useful for beginners and professionals, and focused on getting visitors to try the product.
I did not sell this page for $1,000. The number is a market comparison.
Upwork currently places responsive landing-page design around $300–$1,500 and a full design-and-build system with reusable components and handoff around $750–$2,100. WebFX lists a wider $75–$3,000+ market and prices its own responsive template-based page at $1,125. A custom implementation with shaders, 3D, interaction, revisions, accessibility, and optimization can therefore reasonably cross $1,000. Sources: Upwork web-design pricing, Upwork landing-page pricing, and WebFX pricing.
A screenshot alone is not a $1,000 deliverable. The implemented, tested system is the thing being valued.
Setup: the part that shaped everything else
First, I created the project directory and configured Vanilla JavaScript with Tailwind CSS. I made sure Codex could inspect the structure, run the page, and verify changes.
I isolated the mockup inside the real repository, restricted design work to that directory, and kept product truth in AGENTS.md plus files for architecture, branding, the current task, and the living redesign plan.
Then I enabled the tools:
- Codex as the main coding agent;
- GPT Taste for composition, typography, motion, and landing-page direction;
- Impeccable for critique, accessibility, responsiveness, and final QA;
- Product Design for generating and comparing mockups;
- Canvas UI and Shaders.com for interactive canvas and shader treatments.
The most important setup was persistent context. AGENTS.md and files covering the current task, architecture, branding, and redesign plan explained the product, target visitor, conversion goal, visual references, technical stack, accessibility rules, security boundaries, and protected files.
The context also made staging the source of truth and required production to mirror only verified changes.
That meant I did not have to rebuild the whole project description inside every prompt. It also stopped “make it modern” from becoming fifteen glass cards and a glowing circle with no known occupation.
Finally, I initialized the Codex chat with the full brand and product direction, asked it to inspect the repository and tools, and made it plan before implementing anything important.
My shortened initialization was essentially: read the context, inspect the product, write the redesign brief before editing, stay inside the isolated directory, preserve product truth and routes, and verify each stage.
Choose how to build
There are two useful routes.
One complete first pass
Plan the full page, create the visual direction, implement it, then inspect and revise weak sections. This is fast when the brand direction is already clear.
One section at a time
For experimental work:
Direction → two mockups → choose → improve → implement → inspect
Two mockups give you something real to compare before spending time on code. This works especially well for unusual layouts, shaders, 3D, and interaction.
It is slower, though. Two footer concepts can become seven, and suddenly one footer has an electoral system.
Promptyx mostly used the section-by-section route for Hero, Showcase, For Whom, Pricing, and Footer. FAQ and the closing section were completed together.
The build-and-feedback loop
The Promptyx hero needed to explain the product quickly while feeling premium and approachable.
The final result combines “Your prompts deserve version control” with floating cards showing a prompt, evaluation, improvement, and actions. It demonstrates the product instead of placing a random laptop beside the headline.
For a section like this, I:
- described what it needed to communicate;
- shared references and constraints;
- generated mockups;
- chose and improved one;
- implemented it;
- inspected the real page;
- sent weak areas back as screenshot feedback.
The history includes an ASCII logo, animated ribbon, 3D dashboard, particle effect, and Features grid that were later removed. At one point my entire feedback was basically: “It’s becoming too convoluted.” Reverting was part of the workflow.
When something looked wrong, I cropped the problem, explained what felt wrong, stated what must remain unchanged, and described the desired result. Some ideas were removed completely: an ASCII logo and ribbon made the hero too busy, a particle-scroll effect did not work, and an eight-part Features section was hidden and merged into Showcase.
Official OpenAI examples describe this broad workflow too: building responsive interfaces from screenshots and visual references, then checking and iterating on the result. Official Codex use cases
Final passes
Once the desktop page looked finished, responsiveness testing politely told me otherwise.
Codex tested the page at recorded 1440 × 1000 desktop and 390 × 844 mobile sizes. I reviewed headline wrapping, navigation, CTAs, touch targets, floating elements, shaders, and 3D behavior.
Then I combined the remaining work into one final pass:
- compress assets and reduce unnecessary shader/JavaScript work;
- add lazy loading, mobile fallbacks, and reduced motion;
- check keyboard access, focus, contrast, labels, and semantic structure;
- add SEO metadata, canonical URLs, structured data, sitemap, and robots rules;
- review secrets, dependencies, forms, external assets, privacy, and production configuration.
One mobile failure came from desktop Showcase grid rules winning at the smaller breakpoint. After that was fixed, narrow comparison values still clipped and had to be stacked. The final QA recorded 15 passing checks.
Current Lighthouse results:
| Category | Mobile | Desktop |
|---|---|---|
| Performance | 94 | 95 |
| Accessibility | 100 | 100 |
| Best Practices | 96 | 96 |
| SEO | 69 | 69 |
SEO is lower because the tested page was blocked from indexing, so Google could not reliably evaluate it as a public page. These were informal one-time runs, not averages from repeated tests. The project also recorded 15 passing automated checks. Across the two main tasks there were about 35.7 hours of completed Codex-turn runtime—not my hands-on time, but implementation and verification running during the week.
Lighthouse is evidence, not a complete accessibility or quality certificate.
What made it work
Codex made implementation and iteration surprisingly easy. It did not decide what Promptyx should feel like.
I still supplied the product truth, chose the audience, collected inspiration, compared directions, rejected generic output, noticed visual problems, tested the result, and made the final decisions.
For me, that is the exciting part. A 15-year-old developer with no design experience could create something far beyond what I expected—not because design stopped mattering, but because the distance between an idea and a working interface became much smaller.
You do not need one perfect prompt. You need a useful loop.
Top comments (0)