A quick guide to analyzing a crypto project’s website

Mobile version

To save time, start on your phone. On mobile, you can quickly spot most of the issues vibe coders tend to make. The site should look fine on smartphones, tablets, and other screens. A developer always checks responsiveness, and this is where people who just generated a site and never tested it often give themselves away.

Check the following:

• content doesn’t spill beyond the screen
• text isn’t cut off
• buttons don’t overlap
• horizontal scrolling appears only where it’s actually needed
• elements don’t “jump” after loading
• menus and modal windows open and close properly.

Also try doing a zoom-out — not zooming in, but zooming out. If at some point the content starts spilling off the screen, or the whole page breaks after a single element — that’s a bad sign.

Mobile version of the Throne website.

Desktop Version

1. We evaluate the design.

AI-built websites often rely on generic templates. They look like standard landing pages, not like a product a team of designers and developers actually worked on. If it’s a crypto startup, spending $1,500 on a designer and a developer is totally realistic. The site is mostly used by younger users, so it should feel fresh, stylish, and distinct from other projects.

Pay attention to:

• non-standard shapes
• geometry
• large typography
• animations
• clean typography
• overall visual cohesion.

A simple test — mentally swap out the logo and the project name for any other ones. If the site still looks fine afterward, you’re probably looking at a generic template, not a design made for a specific product.

Comparison of the Throne website design with a typical landing page.

2. Check animations and speed.

Scroll through the page and look for complex interactive elements: animations, data tables, charts, and other components. The page should load fast, and the animations should run smoothly. Good examples:

• smooth theme switching
• micro-interactions
• hover effects
• scroll animations
• equally smooth scrolling up and down.

If the animations lag, stutter, or break nearby elements, that’s already a bad sign. A well-built site should run reliably not only when static, but also during transitions, scrolling, and hover states.

3. Look for visual bugs.

Content should not overlap other elements or suddenly shift position. Check for the following issues:

• the table scrolls only in one direction
• an element shifts when you hover over it
• text spills outside the block
• buttons overlap
• elements jump during loading
• the interface breaks when you resize the window.

If you see bugs like these, the site most likely was not properly tested.

Examples of visual bugs.

4. Check buttons and links.

Click every available element:

• buttons should work
• all links should open, and there should be no empty sections
• menus and modal windows should close
• interactive elements should not freeze.

On desktop, also check the cursor. On a clickable element, it should turn into a pointer — a “hand” cursor. If a button looks clickable but the cursor does not change, it may indicate a sloppy implementation.

Additional Tests

Checking the 404 Page

Open a non-existent URL, for example, textsite.encrypted/asdhkljfa.

The site should display a proper 404 page — “Page not found.” Red flags:

• a black screen
• only a large 404 label
• no button to return to the homepage
• the site does not handle non-existent pages at all
• a generic server error is displayed

A good 404 page keeps the project’s style and helps users get back to the homepage.

Comparison of a proper 404 page and a standard 404 error.

Finding the Project’s GitHub

Find the project’s GitHub and check:

• the date of the last commit
• how regularly it is updated
• the number of contributors
• repository structure
• whether there is a README and documentation
• open tasks (issues)
• whether the repositories match the stated product.

A large project may have a GitHub organization rather than a personal profile. That’s normal. The look is different, but you can still check the activity and quality of the repositories.

On its own, a single wonky block or a broken button doesn’t prove anything. But if the site falls apart on mobile, elements overlap, links don’t work, and no one has even finished basic things like a 404 page — that already shows the team’s attitude toward the product.

That said, the website is only the external layer of the project, and these days you can make it look decent very quickly. That’s why it’s important to look deeper — review the GitHub, update history, developer activity, and repository structure. This gives a much clearer picture of whether the project is actually alive at all, and how many people are working on it.