DEV Community: Khaled Sabry

How to Extract a Website’s Design System into DESIGN.md for Your AI Builder

Khaled Sabry — Wed, 21 Oct 2026 13:18:52 +0000

Your AI builder has produced a working website. But visually, it feels like the same website everyone else is generating.

You ask for something more distinctive. The gradient changes, the cards get larger, and the overall style stays familiar.

If you use Lovable, Claude, Codex, Replit, or Cursor, you may have run into this problem: you know which websites you like, but translating that preference into implementation instructions takes work.

This article walks through a practical workflow with Preveo:

Extract design guidance from a reference website.
Put that guidance in a DESIGN.md your AI builder can use.
Apply it to your own project.
Evaluate the implementation and correct the differences.

Why another “make it modern” prompt may not help

“Modern” can mean a spacious editorial layout, a compact dashboard, or a bright product landing page. It does not specify the decisions your builder needs to make.

A useful design brief explains the relationships between elements: how headings compare with body text, how colors communicate hierarchy, how spacing groups information, and how repeated components stay consistent.

Design area	What the guidance should clarify
Typography	Heading hierarchy, body text, and label treatment
Colors	Roles for backgrounds, text, accents, and borders
Spacing	Padding, gaps, and distance between sections
Layout	Content widths, alignment, and arrangement
Components	Shared styling for buttons, cards, and navigation

Without this context, a builder has to fill in the gaps. Those guesses can take you back toward the same familiar visual patterns.

What is DESIGN.md?

A DESIGN.md is a Markdown file containing your project’s design guidance. It gives you a readable reference you can keep with the code, edit as decisions change, and share with teammates or AI agents.

It does not have a universal schema, and creating the file does not guarantee that every tool will discover it automatically. Explicitly tell your builder to read and apply it.

The useful part is the content: concrete rules that reduce ambiguity during implementation and review.

1. Extract a reference website’s design rules

Preveo’s extraction workflow is designed to turn a reference website into design instructions in under 30 seconds. Timing can vary by page and run.

To use it:

Open the Preveo design-system macro.
Click Use this Macro.
Visit the website whose visual style you want to use as a reference.
Open the Preveo extension and hit Run.
Review the extracted typography, colors, spacing, layout rules, and component styles.

Choose a reference that fits the kind of product you are building. A marketing page can provide useful inspiration for your landing page, but it may offer little guidance for a complex settings screen.

2. Review the output before adding it to your project

The extraction gives you a starting point. Check that it captures the characteristics you actually want to carry into your project.

Ask yourself:

Does the guidance explain the visual hierarchy?
Are the color roles clear enough to apply consistently?
Does the spacing guidance preserve the reference’s density or openness?
Which components need additional rules for my product?

A visible page cannot establish every rule in a website’s internal design system. You may need to add guidance for forms, validation, loading states, or other interactions that the reference does not show.

Save the reviewed instructions as DESIGN.md in your project, or pass the content directly to your builder if that better suits your workflow.

3. Give the builder a scoped implementation task

Attach or reference the document and explain where it should apply. Here is an example prompt:

Read DESIGN.md and use it as the design reference for this project.

Start by applying it to the homepage:
- Follow its typography hierarchy and color roles.
- Use its spacing and layout principles.
- Apply consistent styles to repeated components.
- Adapt the reference to our content and responsive layouts.
- Preserve existing functionality.

After implementation, summarize any places where you had to
interpret or extend the design guidance.

Starting with one representative page gives you an opportunity to review the interpretation before extending it across the project.

Use your own branding, content, and assets. The reference should help you articulate a visual direction that fits your product.

Built With AI? Give Visitors a Reason to Trust Your Website.

Show the care behind your website with Preveo's Human Made Design Score badge. Evaluate your design, improve generic details, and share the results with visitors.

preveo.io

We Reviewed an AI Startup’s Website with Preveo. Here’s What Its Founder Said.

How three Preveo evaluations of Baani AI’s website covered UX copy, cross-device performance, and SEO—and what its founder said when we shared the reports.

    <div class="color-secondary fs-s flex items-center">
        <img
          alt="favicon"
          class="c-embed__favicon m-0 mr-2 radius-0"
          src="https://preveo.io/icons/preveo-logo-v5-mini.webp"
          loading="lazy" />
      preveo.io
    </div>
  </div>
</div>

Worried your Website Looks AI Slop to visitors? here, this is to change that...

Khaled Sabry — Sat, 17 Oct 2026 15:37:32 +0000

You know that feeling when you open a website and think… “Yeah, another AI slop”?

The familiar layout. The headline that could belong to almost any business. The same cards, gradients, and illustrations you’ve seen everywhere else.

You don’t want that to be someone’s first impression of your website, especially when you’ve spent hours making it your own.

You rewrote the copy until it sounded like you. Replaced the placeholder images. Fixed the mobile layout. Adjusted the typography and spacing until the page finally felt right.

Your visitors see the finished website and still think it is AI designed and will probably is good enough… that doesn’t give you the credit for all the work you have done behind the scenes.

That’s why by adding a Human Made Design Score badge: a way to share your website’s design evaluation on how much it is AI and how much it is from a person directly on your landing page.

“Does my site look like a person designed it?” Preveo’s macro evaluates how intentional, distinctive, and polished your website looks. It highlights the details that support that impression, identifies areas that feel generic, and suggests improvements.

Once you’ve reviewed your results, you can add your score badge to your landing page. Only if it is high other than that go back and optimize it to be more human like designs.

For visitors, the badge offers a visible starting point. They can see the score making them sure that it is verified the quality is not the level of AI slop, then can click through to inspect the evaluation behind it: what was assessed and which details supported the result

That transparency is where the badge can help build credibility. You’re giving people something instantly gives them assurance it is not another AI slop

Getting started is simple:

Go to Preveo.io and click Does my site look like a person designed it?
Click “Use this Macro.”
Open your website, launch the Preveo extension, and hit Run.
Review your score and the suggested fixes.
Make improvements, run the evaluation again, and add your badge to your landing page.

We Reviewed an AI Startup’s Website with Preveo. Here’s What Its Founder Said.

Khaled Sabry — Tue, 13 Oct 2026 13:59:32 +0000

A real-world case study of how three AI-powered website evaluations helped start a conversation about better UX, performance, and Google visibility.

Building an AI product is hard. Getting people to discover it, understand its value, and sign up can be even harder.

A founder can spend months building something genuinely useful, only to lose potential customers because the landing page doesn’t explain the product clearly, performs inconsistently across devices, or isn’t structured effectively for search engines.

That’s exactly the kind of problem we’re trying to solve with Preveo.

Recently, we discovered Baani AI, an AI product focused on Indian-language voice typing and meeting summaries.

Instead of simply reaching out to its creator and asking him to try Preveo, we decided to do something different.

We evaluated the website first, generated three reports, and shared the results with the founder.

His response made the experiment worthwhile.

The Product: Baani AI

Baani AI addresses an important problem: making voice-based productivity tools more useful for people who speak Indian languages.

The product supports workflows such as converting spoken language into editable text and producing meeting summaries and action items.

It’s a compelling idea, particularly for users who naturally switch between Indian languages and English.

But even a promising product faces three important questions when someone lands on its website:

Can visitors immediately understand what the product does and why they should try it?
Does the website deliver a good experience on different devices?
Can search engines understand the content and connect it with relevant searches?

We wanted to see how Preveo could help answer these questions.

Three Evaluations, Three Opportunities to Improve

We ran three different Preveo evaluations, each approaching the website from a different perspective.

1. Is the Website Communicating Its Value?

The first evaluation focused on the landing page’s written content.

When someone discovers an unfamiliar AI product, they often decide within seconds whether to continue exploring.

The headline, supporting text, feature descriptions, and calls to action all influence that decision.

A website can explain what a product technically does without clearly communicating why someone needs it.

Using Preveo’s UX Copy & Text Optimization Audit, we evaluated the landing page’s messaging and identified opportunities to make its content clearer, more persuasive, and better aligned with visitor expectations.

The evaluation focused on questions such as:

Does the headline communicate a meaningful benefit?
Are the product’s capabilities explained in language potential customers can understand?
Is there a clear reason to sign up or try the product?
Could any wording create confusion or hesitation?

This matters because bringing more visitors to a website is only part of the challenge. Visitors also need to understand what makes the product worth trying.

Preveo turns this kind of evaluation into a visual report that can be shared with the team and used to guide copy improvements.

Explore Baani AI’s UX Copy & Text Optimization Report

2. Performance: Does the Website Work Well Across Devices?

Website performance across five devices.

For a product trying to attract new users, speed is part of the first impression.

A website that loads quickly on a powerful laptop might behave very differently under mobile conditions.

And because many potential customers discover products through their phones, looking at only one device can leave important problems unnoticed.

We used Preveo’s Page Performance Cross-Device Comparison to examine the landing page under different device conditions.

Rather than treating performance as a single number, this kind of evaluation helps teams compare the experience across devices and understand where investigation is needed.

The report is designed to make performance differences more visible and easier to discuss.

This is especially important for small teams, where developers need to decide which improvements deserve attention first.

Performance also contributes to page experience, although improving performance alone doesn’t guarantee better Google rankings.

Explore Baani AI’s Cross-Device Performance Report

3. SEO: Can Google Understand the Website?

UX and text optimization.

A good product doesn’t automatically become a discoverable product.

Search engines need accessible, meaningful content to understand what a website offers and when it might be relevant to a search.

For Baani AI, potential search topics include Indian-language voice typing, transcription, and AI meeting summaries.

We used Preveo’s SEO Improvement Report to examine the landing page’s on-page search optimization.

The evaluation focused on areas such as page metadata, heading structure, content clarity, and other signals that help search engines interpret the page.

The objective wasn’t to promise a higher position on Google.

It was to identify improvements that could make the page easier to understand, better structured, and more relevant to potential visitors.

For early-stage founders, that distinction matters.

You can’t force Google to rank a page. But you can improve the information and structure that Google uses to evaluate it.

Explore Baani AI’s SEO Improvement Report

What Happened When We Shared the Reports?

After completing the evaluations, we contacted Rajveer, the creator of Baani AI.

We opened by acknowledging the potential we saw in his product.

Then, instead of sending a generic product pitch, we shared the three reports and explained why we thought each one was relevant.

We talked about making the landing page more persuasive, investigating cross-device performance, and improving its structure for Google Search.

We also included a link to Preveo’s wider collection of evaluation tools, such as its AI recommendation-readiness checks.

The entire outreach was centered on his website, not on promoting ours.

And Rajveer responded:

"Nice to see the Reports about Baani Ai, My team is already working on these problems. I loved your product."

That response was particularly encouraging for two reasons.

First, he recognized the problems as relevant enough that his team was already working on them.

Second, he explicitly expressed appreciation for Preveo.io.

We didn’t need to convince him that website quality mattered. The reports connected with issues his team already understood.

The Bigger Lesson

Founders building with AI tools can create and launch applications faster than ever.

But generating a working website doesn’t automatically make that website effective.

You still need to know whether people understand it, whether it performs well across devices, whether search engines can interpret it, and whether it creates enough confidence for someone to take action.

That’s why we built Preveo.

Not simply to tell someone their website has problems, but to help them see what needs attention, understand why it matters, and get guidance on how to improve it.

Want to see what Preveo finds on your own website?

Explore the Preveo Macro Library and run an evaluation on your website.

Disclosure: This case study is written by the team behind Preveo. Rajveer’s response is quoted from a direct exchange. Baani AI is featured as an independently evaluated product; this article does not imply a paid partnership, formal endorsement, or confirmed implementation of the recommendations.

CSS Works in Chrome but Not Safari or Firefox? A Real Example and Fix

Khaled Sabry — Mon, 12 Oct 2026 12:01:44 +0000

We've all been there.

You write some CSS, open your page in Chrome, and everything works exactly as expected.

Then you open Safari or Firefox.

Suddenly, something that should be simple behaves completely differently.

I recently came across an interesting Reddit discussion in r/css where a developer encountered exactly this problem.

The interesting part? It wasn't a complicated layout, JavaScript framework, or browser animation.

It was a small CSS example involving @property and container style queries.

I decided to reproduce the problem, compare its rendering across browsers using Preveo, and then test a possible fix.

Here's what happened.

1. The Original Problem: Same CSS, Different Results

The original Reddit post, titled "Possible CSS Bug", was published on August 12, 2026.

The developer created a minimal example using a registered CSS custom property.

The CSS looked like this:

@property --im-a-color {
    syntax: "<color>";
    inherits: false;
    initial-value: red;
}

.red {
    --im-a-color: red;
}

.blue {
    --im-a-color: blue;
}

@container style(--im-a-color) {
    h1 {
        color: green;
    }
}

And the HTML contained three headings:

<div>
    <h1>I should be black</h1>
</div>
<div class="red">
    <h1>I should also be black</h1>
</div>
<div class="blue">
    <h1>I should be green</h1>
</div>

The expected result was straightforward:

Element	Expected color
First heading (default)	Black
Second heading (`.red`)	Black
Third heading (`.blue`)	Green

The reason is the registered custom property's initial value.

Since --im-a-color starts at red, a boolean style query should evaluate to true only when its computed value differs from that initial value.

Chrome rendered the example as expected, but the original developer reported different behavior in Safari and Firefox.

This raised an interesting question:

Was the CSS wrong, or were browsers interpreting the same CSS differently?

Open the original JSFiddle

2. Why This CSS Is Interesting

The key line is:

@container style(--im-a-color)

Unlike a traditional media query, a container style query can apply CSS based on a custom property's computed value on an ancestor.

When using the boolean form with a registered custom property, the condition is supposed to match when that value differs from its registered initial value.

In our case:

Initial value: red
.red value: red
.blue value: blue

Therefore, only the blue example should receive the green heading style.

This isn't simply about whether a browser supports container queries. It's about whether its implementation produces the expected result for this particular condition.

According to MDN's documentation on container style queries, registered custom properties have specific matching behavior based on their initial values.

That makes the original Reddit example particularly useful: it's small enough to isolate one browser behavior without introducing unrelated layout complexity.

3. I Ran the Example Through Cross-Browser Testing

Instead of trying to diagnose the problem by switching browsers manually, I used Preveo, a tool I've been building to evaluate websites and identify UI problems.

One of its capabilities is comparing how the same webpage renders in different browser engines:

Chromium
Safari (WebKit)
Firefox (Gecko)

The idea is simple: load the same page in multiple browsers, capture the rendered results, and compare them visually.

For this test, I used the original JSFiddle and ran a cross-browser evaluation.

Before Fix — Preveo Report

View the original cross-browser evaluation

The important thing wasn't just identifying which browser looked different. It was having a reproducible example and a visual reference that could be checked again after making a code change.

This is especially useful with CSS because two browsers can accept the same declarations while producing different visual results.

And when that happens in a real application, the consequences can be much more noticeable than a heading having the wrong color.

Imagine the same kind of difference affecting a navigation bar, pricing card, product button, or an entire theme.

4. The Fix: Be Explicit About the Value

For this particular example, I changed the container query from a boolean condition to an explicit value comparison.

Before:

@container style(--im-a-color) {
    h1 {
        color: green;
    }
}

After:

@container style(--im-a-color: blue) {
    h1 {
        color: green;
    }
}

It's a small change, but an important one.

The original condition asks:

Is the computed value different from the property's initial value?

The updated condition asks:

Is the computed value blue?

That is a more precise statement of what this particular example needs.

I also added an explicit default heading color:

h1 {
    color: black;
}

This ensures the intended fallback appearance is clear rather than depending on inherited or browser-default text colors.

The updated example also includes basic HTML document metadata and a small JavaScript diagnostic that logs the computed custom property and heading color.

Open the updated JSFiddle

An important technical distinction

The explicit query is a practical workaround for this use case, not a universal replacement for boolean style queries.

For example, if the custom property were changed to green, the original boolean query should still match because green differs from red.

The explicit blue query would not match.

So this fix makes sense when the intended design is specifically tied to the blue value. It does not establish that the original CSS was invalid, nor does it resolve the underlying browser implementation discrepancy.

5. Running the Test Again

After modifying the CSS, I evaluated the updated example through the same cross-browser workflow.

After Fix — Preveo Report

View the updated cross-browser evaluation

Here are the two versions if you want to compare them yourself:

	Original	Updated
CSS example	Before JSFiddle	After JSFiddle
Cross-browser evaluation	Before report	After report

The useful part of this workflow is being able to evaluate both versions rather than relying on one successful Chrome test.

A proper regression check should verify that the updated result matches the intended appearance in every browser tested, not just that it looks better in one.

For a small example like this, that means confirming the heading colors.

For a production website, it could mean comparing entire pages, typography, component styles, and layout behavior.

6. What I Learned from This Example

There are three things I think developers should take away from this.

1. Browser support doesn't always mean identical behavior

Seeing a feature listed as supported doesn't guarantee that every browser version handles every edge case identically.

That doesn't automatically make one browser right and another wrong. The specification, implementation details, and exact browser versions all matter.

2. A small reproducible example is incredibly valuable

The original developer reduced the problem to three headings and a few CSS declarations.

That made it much easier to understand what was being tested.

If you encounter an unexpected rendering difference, isolating the smallest possible example is often more productive than debugging an entire application.

3. Test the fix across browsers, not just where the problem appeared

It's possible to fix something in Safari and accidentally change the appearance in Chrome.

That's why I prefer comparing the original and updated versions across multiple browser engines.

The goal isn't simply to remove one visual difference.

The goal is to make sure the intended experience works consistently for everyone.

7. Why I Think Cross-Browser Testing Still Matters

Modern frontend development has become dramatically faster.

We have AI coding assistants, component libraries, CSS frameworks, and tools that can generate entire interfaces from a prompt.

But there's a problem.

Generating the interface is not the same as validating the interface.

Your application might work perfectly in the browser you use for development while looking different for someone opening it in Safari or Firefox.

And often, you won't notice until a customer reports it.

This is one of the problems I'm trying to address with Preveo.

Instead of manually opening every page in multiple browsers and trying to spot differences, I wanted a way to evaluate browser rendering side by side, identify meaningful inconsistencies, and produce actionable suggestions for fixing them.

The example from Reddit is small, but it illustrates the larger issue perfectly.

Even a few lines of valid-looking CSS can deserve cross-browser testing.

Final Thoughts

What started as a Reddit post about a possible CSS bug became an interesting example of why cross-browser validation matters.

The practical fix for this case was small:

/* Before */
@container style(--im-a-color) { /* ... */ }

/* After */
@container style(--im-a-color: blue) { /* ... */ }

But the bigger lesson is that CSS working in one browser isn't proof that it works everywhere.

If you're building websites—whether manually, with React, using Lovable, or with an AI coding assistant—it's worth checking how the actual result looks across browsers before shipping.

You can explore the example yourself:

And if you want to evaluate your own website across Chromium, Safari, and Firefox, you can try Preveo.io.

Have you ever had CSS work perfectly in Chrome but behave differently in Safari or Firefox? I'd be interested to hear which browser differences have caused you the most trouble.

I Improved My Website’s SEO Score from 77 to 96 Using One AI Prompt

Khaled Sabry — Sun, 11 Oct 2026 07:31:35 +0000

How I used an AI-powered SEO evaluation, generated a fix prompt, and let Codex handle the improvements.

I've been building my website for a while, and like many developers using AI tools, I assumed that if the page looked good and worked properly, the SEO was probably fine too.

Turns out, I was missing quite a few things.

I decided to run an SEO evaluation on my website using Preveo.io to see what could be improved.

My initial score was 77/100.

Not terrible, but definitely room for improvement.

What surprised me wasn't the score itself. It was how many relatively small issues I had overlooked, and how straightforward some of them were to fix.

Instead of spending hours manually going through the findings, I tried something different.

I generated a single AI fix prompt, gave it to Codex, applied the changes, and evaluated the page again.

The result? 77 → 96. A 19-point improvement.

Here's what I did and what I learned.

Step 1: Evaluate the Website Before Changing Anything

One mistake I've made when improving websites is jumping straight into fixes without fully understanding what's wrong.

This time, I wanted to start with an evaluation.

I used an SEO evaluation macro called Improve Page SEO in Preveo.

The macro analyzes the actual webpage, looking at elements such as:

Page title and meta description
H1 and heading hierarchy
Content structure and keyword clarity
Image alt attributes
Internal and external links
Canonical URLs and indexing signals
Structured data

The useful part is that the evaluation isn't just based on how the website looks in a screenshot. It examines the on-page elements that search engines use to understand a website.

After running it, I received a report showing which elements were already in good shape and which could benefit from changes.

My starting score: 77/100.

View my original SEO evaluation

Step 2: Understand What Was Actually Hurting the Score

Going through the findings reminded me that good SEO isn't necessarily about adding more keywords or writing longer content.

Sometimes, it's about making the website easier to understand.

Here are five lessons I took away from the process.

1. Your Headline Should Explain What You Do

A catchy headline is great for marketing, but visitors and search engines also need to understand what your product actually offers.

It communicates an idea, but without supporting context, it doesn't fully explain the product.

A descriptive subheading can help connect that message to what the product does and who it's for.

The lesson: Keep your creative messaging, but make sure the surrounding content provides clarity.

2. Meta Descriptions Deserve Attention

It's easy to spend hours designing a landing page and almost no time reviewing how it might appear in search results.

Your page title and meta description are an opportunity to explain why someone should click.

A good description should:

Communicate what the page offers.
Use natural language.
Match the actual content.
Avoid unnecessary keyword stuffing.

3. Image Descriptions Matter

Not every image needs a long description, but meaningful images should have relevant alt text.

This helps accessibility and gives search engines additional context.

For purely decorative images, an empty alt attribute can be more appropriate.

4. Your Content Needs a Clear Structure

A website can look visually organized while having a confusing heading hierarchy underneath.

Using headings consistently helps visitors navigate content and makes the page structure easier for search engines to interpret.

5. Small Technical Details Are Easy to Miss

Canonical URLs, indexing directives, structured data, and descriptive links aren't always visible in the UI.

That's exactly why reviewing the actual webpage matters.

A visual inspection alone won't tell you whether everything is configured correctly.

Step 3: Generate One Fix Prompt Instead of Fixing Everything Manually

This was my favorite part of the experiment.

Once I had the SEO evaluation, I used its findings to create an AI fix prompt.

The idea was simple:

Rather than manually translate every recommendation into a code change, give a coding agent the relevant evidence and ask it to handle the confirmed issues.

I copied the prompt into Codex, which had access to my website's codebase.

The prompt instructed the agent to:

Review the SEO evaluation findings.
Verify each issue against the actual implementation.
Identify which recommendations were genuinely necessary.
Make the appropriate code changes.
Avoid unnecessary changes just to improve the score.

That verification matters.

AI-generated reports aren't automatically correct, and I didn't want changes made simply because a tool suggested them.

The coding agent could inspect the existing implementation before editing anything.

After the changes, I pushed the updated website and ran the same SEO evaluation again.

Step 4: Run the Evaluation Again

This was the moment I was most interested in.

Did the changes actually improve anything?

The second evaluation came back with a score of 96/100.

Before vs. After

Metric	Before	After
SEO evaluation score	77/100	96/100
Score improvement	—	+19 points
Evaluation method	Preveo SEO Macro	Same macro
Code improvements	Not yet applied	Applied using Codex

View my updated SEO evaluation

One important distinction: This was an improvement in the evaluation score, not proof of a 19% increase in Google rankings or organic traffic.

Search performance takes time to measure, and better on-page SEO doesn't guarantee better rankings.

But it did give me a measurable way to see whether the changes addressed the issues identified in the first review.

And that's valuable on its own.

The Workflow I Want to Keep Using

The whole experience made me think differently about improving websites with AI.

We have plenty of tools that help us build websites quickly.

Lovable, Bolt, Replit, Cursor, Claude Code, and Codex are all examples of how much easier building has become.

But once the website is built, there's another question:

How do you know what still needs improvement?

That's where I think an evaluation-first workflow makes sense.

My Process

Evaluate → Understand → Generate Fix Prompt → Apply Fixes → Re-evaluate

I used Preveo for the evaluation and Codex to make the code changes.

The distinction is useful:

Preveo: Identifies what needs attention and generates actionable findings.
Codex: Reviews the findings, verifies the issues, and implements the code changes.
Preveo again: Re-evaluates the website to measure the improvement.

It also means I don't have to rely entirely on how polished the page looks or whether the coding agent says it's finished.

I can run another evaluation after making changes.

A Few Things I'd Do Differently Next Time

I learned that a higher score shouldn't be the only goal.

Some SEO recommendations may not be appropriate for every page, and adding unnecessary keywords, sections, or structured data just to satisfy a checklist can make the website worse.

Next time, I'd also track:

Google Search Console impressions
Organic search clicks
Indexing status
Search queries and ranking changes
Actual organic traffic over time

That would help distinguish improvements in on-page SEO implementation from actual changes in search performance.

I'd also prioritize recommendations that genuinely help visitors understand and use the website, rather than treating every possible optimization as mandatory.

Final Thoughts

Going from 77 to 96 was satisfying, but the bigger takeaway was the workflow.

I didn't need to manually inspect every metadata field or write individual instructions for each issue.

I could evaluate the page, identify meaningful improvements, let a coding agent implement the verified fixes, and run the evaluation again.

If you're building a website using Lovable, Bolt, Replit, Codex, or any other AI-assisted development tool, I'd recommend trying an evaluation before asking the AI to make random improvements.

You might find problems you didn't even know to look for.

And sometimes, one well-structured fix prompt is enough to make a noticeable difference.

DEV Community: Khaled Sabry

How to Extract a Website’s Design System into DESIGN.md for Your AI Builder

Why another “make it modern” prompt may not help

What is DESIGN.md?

1. Extract a reference website’s design rules

2. Review the output before adding it to your project

3. Give the builder a scoped implementation task

Other Articles

Built With AI? Give Visitors a Reason to Trust Your Website.

We Reviewed an AI Startup’s Website with Preveo. Here’s What Its Founder Said.

Worried your Website Looks AI Slop to visitors? here, this is to change that...

We Reviewed an AI Startup’s Website with Preveo. Here’s What Its Founder Said.

The Product: Baani AI

Three Evaluations, Three Opportunities to Improve

1. Is the Website Communicating Its Value?

2. Performance: Does the Website Work Well Across Devices?

3. SEO: Can Google Understand the Website?

What Happened When We Shared the Reports?

The Bigger Lesson

Other Articles

CSS Works in Chrome but Not Safari or Firefox? A Real Example and Fix

1. The Original Problem: Same CSS, Different Results

2. Why This CSS Is Interesting

3. I Ran the Example Through Cross-Browser Testing

4. The Fix: Be Explicit About the Value

An important technical distinction

5. Running the Test Again

6. What I Learned from This Example

1. Browser support doesn't always mean identical behavior

2. A small reproducible example is incredibly valuable

3. Test the fix across browsers, not just where the problem appeared

7. Why I Think Cross-Browser Testing Still Matters

Final Thoughts

Other Articles

I Improved My Website’s SEO Score from 77 to 96 Using One AI Prompt

How I used an AI-powered SEO evaluation, generated a fix prompt, and let Codex handle the improvements.

Step 1: Evaluate the Website Before Changing Anything

Step 2: Understand What Was Actually Hurting the Score

1. Your Headline Should Explain What You Do

2. Meta Descriptions Deserve Attention

3. Image Descriptions Matter

4. Your Content Needs a Clear Structure

5. Small Technical Details Are Easy to Miss

Step 3: Generate One Fix Prompt Instead of Fixing Everything Manually

Step 4: Run the Evaluation Again

Before vs. After

The Workflow I Want to Keep Using

My Process

A Few Things I'd Do Differently Next Time

Final Thoughts

Resources From My Experiment