Building VisualSnag and Why AI Tools Need Clear Visual Context

Hi! My name is Maksym. For a long time, my professional career was connected with UX/UI and product design, but over the last year I have been focusing more and more on building my own products.

At first, I was building iOS and macOS apps with Swift. Later, I moved to JavaScript and built several apps for Jira and Confluence. After that, the logical thing would have been to stop, focus on marketing the products I had already built, and avoid opening a new repository for at least a few months.

But in practice, when you work on your own ideas, things rarely happen that rationally. Very often, a new product does not start with a big strategy. It starts with a problem that repeats itself often enough that one day you can no longer ignore it.

That is how the idea for VisualSnag appeared.

The idea

Recently, I have been working a lot with AI tools for development and design: ChatGPT, Claude Code, Codex, Figma Make, and other similar tools. They already help a lot with logic, application structure, component generation, code, and fast prototyping.

But while working with these tools, I kept running into the same problem: the visual side of the generated interface often feels too generic. This is especially noticeable with tools like Claude Code.

The interface can be functional, responsive, and technically correct, but it often lacks a clear visual identity, a sense of brand, strong typography, color logic, rhythm, and composition.

Phrases like “make it modern,” “make it beautiful,” or “make it premium” do not give AI enough specific direction. Even for a human designer, these would be weak instructions without references, context, and a clearer explanation of the expected result. With AI, this becomes even more obvious, because the model tries to fill in all the gaps on its own and often chooses the safest and most typical solution.

I started thinking about how to make this process more precise.

If a person already has a website or an image reference that communicates the right mood, style, or visual logic, why not turn that reference into structured rules for further work with AI?

VisualSnag lets you paste a website URL or upload an image reference and get a ready-to-use visual system for AI-assisted building: colors, typography, layout rules, CSS variables, design tokens, a style brief, and AI prompts.

The idea is not to copy someone else’s website. The goal is to understand its visual logic and turn it into practical materials that can be used in your own project.

Why not just another prompt generator?

At first glance, VisualSnag could be described as a prompt generator for design. But I did not want to build another tool that simply returns a long text with generic phrases.

The problem of visual direction in AI-assisted development is broader than that. Users do not need only a prompt. They need specific anchors that can be transferred into the development process:

• which colors to use;
• what role primary, secondary, accent, and background colors should have;
• what typography logic works for headings, body text, labels, and buttons;
• what border radii, spacing, and interface density are typical for the reference;
• what overall UI mood should be preserved;
• which CSS variables can be used right away;
• which prompt can be pasted into ChatGPT, Claude, Codex, Cursor, Lovable, or another AI builder.

That is why I see VisualSnag not as a prompt generator, but as a translator between a visual reference and practical rules for AI-assisted development.

A user may see a website or an image they like, but they cannot always quickly explain why it works. VisualSnag is meant to help extract not a surface-level similarity, but the visual structure behind the reference: colors, typography, composition principles, the character of UI components, and rules that can later be adapted to a new product.

Development

The name VisualSnag came from the idea of “snagging” or “catching” a visual style. I wanted the product to avoid sounding like another technical analyzer and instead have a simple metaphor: the user gives the tool a website or an image, and the service catches the style logic behind it.

After the idea, name, logo, and first screens were ready, I moved into development.

The stack I chose was:

Frontend

Vite, React, TypeScript, Tailwind CSS.

Backend

Node.js, Express.

Database

PostgreSQL.

ORM

Prisma.

Hosting

Railway.

URL analysis

Playwright / Chromium.

This stack made sense for several reasons.

First, I already had experience with JavaScript and TypeScript after building apps for the Atlassian Marketplace. Second, I needed speed and flexibility, not an overly complex architecture for the first version of the product. Third, Railway made it possible to quickly deploy both the application and PostgreSQL in one environment.

Vite and React gave me a fast frontend. Tailwind CSS helped me build the interface quickly while keeping control over the visual system. Node.js and Express covered the API layer.

Of course, this does not mean everything worked on the first try. Especially after Playwright and server-side Chromium entered the project.

How the product works

In the first version, I tried to make the user flow as clear as possible.

A user can:

1. Paste a website URL.
2. Upload one or more image references.
3. Start the analysis.
4. Receive a structured result.
5. Copy the needed blocks.
6. Download files for further work.

As an output, the product generates several types of results.

Style Brief

This is a short description of the visual direction. It explains the general character of the reference: mood, density, typography logic, color behavior, composition approach, and overall UI mood.

Colors

The service identifies the main palette and tries to distribute colors by role: background, surface, text, primary, accent, border, and so on.

This is important because a random set of HEX codes is not very useful on its own. It is much more helpful to understand what each color is responsible for.

Typography

A separate section describes the typography direction: headings, body text, buttons, labels, and accents.

It is not always possible or necessary to copy the exact font from a reference. More often, it is more important to understand the typography logic: geometric, editorial, tech, playful, minimal, high-contrast, or neutral.

Layout rules

This block describes the principles behind the interface layout: spacing, grid, density, container width, the character of cards, sections, CTAs, and visual rhythm.

Component DNA

This is an attempt to describe how UI elements behave within the style: cards, buttons, badges, inputs, sections, and navigation.

I wanted the output to be useful not only for simple landing pages, but also for more complex interfaces.

CSS Variables

The service generates variables.css, which can be used as a starting point for the frontend. It is not a final design system, but it gives a useful base layer for fast prototyping.

Design Tokens

tokens.json provides a structured format that can be used in AI tools, custom scripts, or design processes.

AI Prompts

VisualSnag also generates prompts for AI-assisted building.

The idea is that the user does not have to write the style instructions from scratch. They can immediately paste the generated description into ChatGPT, Claude, Codex, Cursor, Lovable, Figma Make, or another AI tool.

Downloads

The result can be viewed on the website, but it can also be downloaded as working files:

• STYLE.md
• variables.css
• tokens.json

This is important because these files can become part of a real workflow. They are not just text on a screen. They can be copied into a project, sent to another AI tool, saved as documentation, or used as a starting point for further design and development.

Architecture

At the architecture level, I did not try to build a complex system in the first version. The main task was to create a stable path from input to output.

The flow looks roughly like this:

1. The user submits a URL or uploads an image.
2. The backend receives the request and creates a database record.
3. For a URL, the page analysis process starts.
4. For images, visual data is processed.
5. The data is transformed into an internal structured format.
6. A style brief, tokens, CSS variables, and prompts are generated.
7. The result is returned to the frontend.
8. The user copies the blocks or downloads the files.

PostgreSQL is used to store users, requests, statuses, results, and technical metadata.

I also spent time thinking about what data should and should not be stored. VisualSnag works with references, and references can be work-related, private, or temporary. I did not want the product to become an uncontrolled storage for everything a user had ever uploaded.

So I decided to store only what is needed for the product to work: authentication, exports, and access to previous results. Anything unnecessary should not end up in the database just because it is technically possible to store it.

Problems and solutions during development

During development, I ran into several technical and product challenges. They showed that even a tool that looks relatively simple from the outside can have many internal details.

1. AI output must be structured, not just nicely written

The problem: if you simply ask AI to describe the style of a website or an image, the result is often too general. It may be well-written, but not practical enough.

For example, a phrase like “modern and clean interface with strong visual hierarchy” sounds fine, but it does not provide enough material for actual development.

I needed an output that could be used immediately. Not just a description, but specific blocks: colors, typography, layout rules, CSS variables, tokens, and prompts.

The solution: I made the output as structured as possible. Each block has its own role and expected format.

If it is colors, the colors should have roles. If it is typography, there should be a breakdown by text types. If it is CSS variables, they should be ready to use. If it is a prompt, it should be written in a way that can be pasted into an AI builder without extra editing.

The main takeaway: AI inside a product should not simply generate text. It should return a predictable and useful artifact.

2. It is important to explain that the product does not copy websites

The problem: any tool that analyzes the visual style of a website can be misunderstood. I did not want to build a service for copying other people’s websites. That would not only be legally and ethically wrong, but also less interesting from a product perspective.

The goal is different: to help users understand the visual logic of a reference and adapt it to their own project.

The solution: I deliberately avoid phrases like “clone any website.” Instead, I use terms like visual system, style brief, design rules, and AI-ready prompts. These describe the product more accurately.

The service is not meant to transfer someone else’s website into your own project. It is meant to help read the style principles and turn them into a clear foundation for your own interface.

3. Running Chromium in production

The problem: for URL analysis, it is not enough to simply fetch HTML. The tool needs to work with the page as an actual rendered website. Styles, loaded fonts, computed styles, visual structure, responsiveness, and the way a page looks after JavaScript execution all matter.

For this, Playwright / Chromium is needed.

Locally, this approach works fairly smoothly. But in a production environment with containers, additional issues appear: system dependencies, fonts, permissions, memory, timeouts, and browser launch stability.

The solution: I configured the environment for Chromium, added the required dependencies, limited concurrency, and made timeout handling more careful. I also had to account for the fact that different websites load at different speeds, use different numbers of scripts, and behave differently during rendering.

4. Websites have very different structures

The problem: there is no single universal way to extract visual style from a website.

One site has well-structured CSS variables. Another uses Tailwind classes. A third one has inline styles. A fourth builds many visual elements through JavaScript or SVG.

Colors can be in CSS, background images, gradients, SVGs, or decorative elements. Fonts can load from different sources. Layout can change significantly depending on viewport, cookies, or A/B tests.

The solution: I did not try to build a system that perfectly understands every property of every website. Instead, I chose a practical approach: collect the most useful signals from the DOM, computed styles, visual structure, and page screenshot, then convert them into a clear style format.

For this type of product, absolute technical reproduction of every pixel is less important than a useful interpretation of the visual system.

5. The interface must make sense to both designers and developers

The problem: VisualSnag sits between design and development.

For designers, references, style, colors, composition, and typography are important. For developers, CSS, tokens, prompts, exports, data structure, and the ability to use the result quickly in their workflow are important.

If the product is too design-oriented, developers may find it less clear. If it is too technical, it may lose users who think through visual references.

The solution: I split the output into two levels.

The first level is human and visual:

• Style brief
• Colors
• Typography
• Layout rules
• Component DNA

The second level is practical and technical:

• CSS variables
• Design tokens
• AI prompts
• Downloads

This way, the user can either quickly understand the style or immediately take concrete materials for work.

What I did not build in the first version

I deliberately did not try to turn VisualSnag into a large platform right away.

The first version does not include:

• team workspaces;
• a full project library;
• a Figma plugin;
• a browser extension;
• a marketplace of ready-made style systems;
• complex collaboration features;
• automatic generation of a finished website from a reference.

At the start, it was important to test the main hypothesis:

Do people need a tool that turns a website or image reference into a practical visual system for AI-assisted development?

That is why the first version focuses on the core scenario:

1. Provide a reference.
2. Get structured style output.
3. Copy a prompt or download STYLE.md, variables.css, and tokens.json.
4. Use it in an AI-assisted workflow.

During development, I once again became convinced that AI needs not only a functional task, but also clear visual context.

A reference is not an instruction by itself. It needs to be broken down into specific rules: colors, typography, rhythm, layout, components, spacing, and accents.

That is why useful AI output must be structured, not just presented as a long text without clear sections. When the result is separated into Style Brief, CSS variables, design tokens, and AI prompts, it becomes much easier to use in a real project.

What is next

The nearest goal for VisualSnag is to collect feedback from people who actually use AI tools to create websites, applications, and interfaces.

I want to understand:

• how useful the Style Brief is;
• whether the CSS variables are accurate enough;
• whether tokens.json is convenient to use;
• which export formats are missing;
• which prompts work best for different AI builders;
• whether users need to compare several references at once.

Potentially, the product can move in several directions:

• deeper URL analysis;
• better screenshot processing;
• comparison of multiple references;
• separate output formats for Cursor, Claude, Codex, Lovable, Bolt, Framer, and Webflow;
• a library of saved visual systems;
• team workspaces;
• a Figma plugin;
• a browser extension for quickly analyzing the style of any page.

VisualSnag is not meant to copy other people’s websites. It is an intermediate layer between a visual reference and AI-assisted development. Its goal is to make visual direction clear, structured, and usable in a real project.

Links

Try VisualSnag here:
https://www.visualsnag.com/

Contact me directly:
[e-mail]