From a PDF Design to a Functional Landing Page: Exploring AI-Assisted Web Development with Codex

A practical experiment in recreating a premium UI/UX design from a PDF—and what it reveals about building the complete system behind it.

#Introduction

Recently, I came across an Upwork project that caught my attention.

The project wasn't simply asking for a static landing page. The requirements described a broader system involving a functional website, content management, and a more complete digital experience.

Before deciding how I would approach the entire project, I wanted to answer a simpler question:

How quickly can I take the provided design reference and turn it into a polished, responsive frontend using modern AI-assisted development tools?

So I decided to run a small experiment.

I downloaded the design attachment provided with the project, analyzed the visual structure, and used OpenAI Codex to recreate the UI/UX as a standalone landing page.

The goal wasn't to build the complete system yet.

This was Part 1: the UI/UX experiment.

The next stage will be to explore the architecture and implementation of the complete system described in the project requirements.

#The Starting Point: A PDF, Not a Figma File

The design reference I had available was a PDF containing screenshots of the landing page.

There was:

• No original HTML
• No CSS
• No Figma design system
• No original image assets
• No component library
• No source code

That creates an interesting frontend challenge.

Normally, if I'm given a Figma design, I can inspect:

• Exact dimensions
• Typography
• Colors
• Spacing
• Grid systems
• Component states
• Assets
• Responsive layouts

With a screenshot-based PDF, most of that information has to be inferred.

So the challenge became:

Can an AI coding agent understand a visual reference and turn it into a maintainable frontend implementation?

#Step 1: Understanding the Design

The first thing I did was analyze the design as a UI/UX engineer rather than immediately writing code.

The page uses a very specific visual language:

• Editorial serif typography
• Warm neutral colors
• Cream and taupe backgrounds
• Dark brown/black hero section
• Large whitespace
• Minimal navigation
• Hand-applied material aesthetics
• Asymmetric editorial layouts
• Subtle visual transitions

The overall design feels more like a premium architectural or interior-design brand than a typical corporate website.

The important part was recognizing that the design isn't simply about colors and typography.

The material itself is part of the brand.

The website needs to communicate:

Texture Craftsmanship Imperfection Warmth Architecture Premium finishes

That became one of the main considerations during the implementation.

#Step 2: Asking Codex to Recreate the Interface

I created a detailed development prompt for Codex, asking it to act as a senior UI/UX engineer and frontend architect.

The instructions emphasized:

• Don't redesign the page
• Treat the PDF as the source of truth
• Recreate the layout as accurately as possible
• Use semantic HTML
• Use modern CSS
• Make it responsive
• Create reusable components
• Use minimal JavaScript
• Implement animations carefully
• Maintain accessibility
• Optimize for performance

I deliberately asked Codex to work iteratively rather than trying to generate everything in one pass.

The basic architecture was:

index.html

assets/
├── css/
│   ├── variables.css
│   ├── style.css
│   ├── layout.css
│   ├── sections.css
│   ├── components.css
│   └── responsive.css
│
├── js/
│   ├── app.js
│   ├── navigation.js
│   ├── animations.js
│   └── accordion.js
│
└── images/

This gave the AI agent a clear boundary between:

• Design tokens
• Layout
• Components
• Sections
• Responsive behavior
• JavaScript functionality

#Step 3: The First Result

The first version successfully recreated the overall structure.

The page contained sections such as:

• Hero
• Brand introduction
• Hand-applied finishes
• Surface options
• Benefits
• Studio
• Six-step process
• Testimonials
• Selected work
• Educational content
• FAQ
• Contact
• Footer

The first version was visually promising.

The color palette was right.

The typography direction was right.

The section hierarchy was right.

But there was one major problem.

The website felt too small inside very large sections.

The content was technically there, but the visual scale was not quite right.

It looked more like a carefully constructed prototype than a finished premium website.

#Step 4: The Second Refinement Pass

Instead of rebuilding everything, I asked Codex to perform a visual QA and refinement pass.

The goal was to compare the implementation against the original reference again and fix:

• Typography scale
• Section width
• Container width
• Card dimensions
• Image proportions
• Horizontal spacing
• Vertical spacing
• Navigation scale
• Portfolio scale
• Contact form size

The second iteration introduced a more deliberate visual scaling system.

For example, the CSS started using larger fluid typography:

.hero-title {
    font-size: clamp(54px, 6.5vw, 96px);
}

.section-title {
    font-size: clamp(43px, 4.8vw, 68px);
}

The layout widths were also expanded to make better use of larger desktop screens.

This was a good example of why I prefer iterative AI-assisted development.

The first AI-generated implementation wasn't perfect.

But instead of throwing it away, I could identify the problems and give the agent a more precise instruction set.

#The Result

The final UI experiment produced a complete, responsive landing page with:

• Editorial typography
• Responsive layouts
• Sticky navigation
• Scroll-based header transitions
• Mobile navigation
• FAQ accordion
• Finish selection interface
• Portfolio layout
• Contact section
• CSS-generated material textures
• Responsive breakpoints
• Lightweight JavaScript

The project is available publicly on GitHub:

View the Umami Walls Landing Page GitHub Repository

The experimental deployment is also available here:

View the Umami Walls UI/UX Experiment

#A Few Things I Learned from the Experiment

The experiment also revealed an important distinction between building a visual prototype and building a production system.

The frontend looks convincing, but some elements are still prototypes.

For example:

#Finish filtering

The interface has filter buttons, but the initial prototype only changes the active state.

A production implementation should actually filter the finish collection.

#Contact form

The prototype demonstrates the UI and interaction, but a production website needs:

• Validation
• API integration
• Email notification
• Database storage
• Spam protection
• Error handling
• Success states

#Real imagery

For a premium wall-finishing company, CSS-generated textures are useful for prototyping.

But the final website should use real photography of:

• Plaster finishes
• Interior projects
• Material close-ups
• Finished walls
• Application processes

That would significantly improve the visual storytelling.

#Real business content

The final system should also replace any placeholder or experimental content with verified business information, real testimonials, real locations, and actual project data.

#What I Think About AI-Assisted UI Development

This experiment reinforced something I've been thinking about for a while.

AI coding agents are becoming extremely effective at translating a visual concept into working frontend code.

But the quality of the final result depends heavily on the developer's ability to:

• Analyze the design
• Understand UX
• Identify visual inconsistencies
• Give precise feedback
• Review generated code
• Understand architecture
• Know what should and shouldn't be automated

AI can generate the code.

But someone still needs to know what good code and good UX actually look like.

In this experiment, the first version was good.

The second version was better.

The difference came from the refinement process.

Is the Complete System Difficult to Build?

This is where the experiment becomes particularly interesting for me.

The landing page itself is not the difficult part.

The UI/UX is a relatively straightforward frontend implementation once the design language is understood.

The more interesting challenge is building the system behind the website.

Based on the requirements of the original Upwork project, I see the larger solution as something closer to:

                    Admin / CMS
                        │
                        ▼
              Content Management
                        │
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
     Finishes        Projects         Articles
        │               │               │
        └───────────────┼───────────────┘
                        ▼
                   Website API
                        │
                        ▼
                Public Frontend
                        │
             ┌──────────┴──────────┐
             ▼                     ▼
         Contact                  SEO
         Leads                 Metadata
             │                     │
             └──────────┬──────────┘
                        ▼
                  Notifications

Depending on the final requirements, the system could include:

• CMS
• Authentication
• Admin dashboard
• Finish management
• Project management
• Gallery management
• Blog/content management
• FAQ management
• Lead management
• Contact forms
• Email notifications
• SEO management
• Image processing
• Search
• Filtering
• API layer
• Analytics
• Deployment infrastructure

That is where my experience as a full-stack PHP/Laravel developer becomes much more relevant.

From UI Experiment to Full System

This UI experiment is therefore only Part 1.

The next step is to take the design and build the actual system behind it.

My preferred approach would likely be something along the lines of:

Frontend
    │
    │
    ▼
Laravel Application
    │
    ├── CMS
    ├── Admin Panel
    ├── REST API
    ├── Authentication
    ├── Content Management
    ├── Media Management
    ├── SEO
    ├── Lead Management
    └── Notifications
             │
             ▼
          Database

The frontend could either remain a lightweight HTML/CSS/JavaScript implementation or evolve into a more component-driven architecture depending on the requirements.

For a project like this, I would focus heavily on content architecture.

The important question isn't only:

"How do we build this page?"

It's:

"How do we make it possible for the business owner to manage this website without needing a developer every time they want to add a finish, update a project, publish an article, or change SEO metadata?"

That's where a proper CMS architecture becomes important.

My Takeaway as a Freelancer

After completing this UI/UX experiment, my conclusion is quite simple:

The frontend design is not the difficult part for me.

I can analyze the visual reference, build the responsive interface, reproduce the design system, and refine the implementation with AI-assisted development tools.

The more interesting part—and the part where I believe I can bring significantly more value—is building the complete system behind the interface.

The UI is just the visible layer.

The real product is the combination of:

UI + CMS + Content Architecture + Media Management + SEO + Lead Generation + Administration + Automation

This experiment gave me a practical way to validate the frontend direction before moving into the larger architecture.

And that's exactly where I want to go next.

Part 1 was about recreating the UI/UX.

Part 2 will be about building the actual system described in the project requirements.

That's where the real engineering challenge begins.

#Project Links

• GitHub Repository — Umami Walls Landing Page
• Live UI/UX Experiment — Umami Walls
• Original Upwork Project Reference

Next: From AI-generated UI to a complete CMS-driven website: designing the architecture, database, admin panel, media system, and content workflow.