SiteScope - Full Case Study

• Too many tools for one job. You open five tabs to get one answer.
• Results that need translation. A score of 73 means nothing unless you know what it means.
• No prioritization. You get a list of 40 issues with no sense of which ones actually matter.
• No design feedback. Every tool measures code and performance. None of them actually look at your design.
• Slow setup. Most tools want an account, a project, a tag on your site. That friction stops people before they even start.

How might we give anyone a full website health report in under 30 seconds, with zero setup?

I looked at the competitive landscape across three categories.

• Professional audit platforms - Semrush, Ahrefs, Sitebulb. Powerful but expensive and built for agencies. Starting at $100 per month. Overkill for most people.
• Developer-focused tools - Lighthouse, PageSpeed Insights, GTmetrix. Free but technical. They give you data without context. You need to already understand the web to use them.
• Design-focused tools - Screaming Frog, Wave, Siteimprove. Each covers one category. None covers all of them.

The gap I found: there is no free, fast, all-in-one tool built for someone who is not a developer. That is the space SiteScope fills.

I am the user.

I have used all of these tools. I have felt the friction. I have spent time translating Lighthouse scores for clients who just wanted to know if their site was good or not.

I thought about three types of people who would use this.

• The freelancer who builds sites for clients and needs to show their work. They want a report they can screenshot and send.
• The founder who built their own site and wants to know if it is working. They are not a developer. They need plain English.
• The developer who wants a quick pre-launch check before shipping. They know what the numbers mean but want them all in one place.

All three need the same thing - fast, clear, and complete. That guided every decision I made.

I looked at four main competitors in depth.

• PageSpeed Insights. Good at performance. Terrible at everything else. Very technical output. No design feedback at all.
• Wave. Great at accessibility. Nothing else. Old UI that has not changed in years.
• Semrush Site Audit. Does everything but costs money and takes time to set up. Built for power users.
• Lighthouse CLI. The most powerful of all of them. But it lives in a terminal and outputs JSON. Not for regular people.

My conclusion: the market has two extremes. Simple but shallow, or deep but complicated. I wanted the middle. Deep but simple.

Before I touched any screens, I defined the visual system.

• Colors: one blue accent (#3A81FF) on a near-white background. Text in three weights of gray - primary, secondary, muted. A clean border color for dividers. The whole palette has maybe six values total.
• Typography: Geist Sans for all headings and interface text. Inter for supporting body copy. Both are clean, modern, and readable at any size. No decorative fonts.
• Spacing: a consistent scale of 4, 8, 12, 16, 24, 32, 48, 64, 100 pixels. Everything aligns to this scale.
• Components: buttons, input fields, badges, cards, section wrappers. All defined before the pages were designed so the whole product feels like one thing.

The design system is not complex. It is consistent. That is what matters.

• Figma - visual design tool. I used it to design the layouts, components, and screens before writing any code.
• Next.js - the frontend framework. It handles the pages, routing, and server-side rendering of the web app.
• React - the JavaScript library that Next.js runs on. Every button, card, and section is a React component.
• Tailwind CSS - utility CSS framework for styling. Used in some parts. The rest uses custom CSS classes in globals.css.
• Playwright - a browser automation library. The backend uses it to open a real Chrome browser, visit the website being audited, take a screenshot, collect HTML, and extract styles and network data.
• Lighthouse - Google's open-source performance tool. SiteScope runs it programmatically to score performance, SEO, and best practices.
• axe-core - the industry standard accessibility testing library. Used to find and categorize accessibility violations.
• FastAPI - the Python web framework that powers the backend. It receives the URL, runs all the analyzers, and returns the results.
• Supabase - the database. Stores every audit report so users can come back to previous results.
• GitHub - version control. All code lives here. Auto-deploys when I push.
• Vercel - hosts the frontend. Fast global CDN. Zero configuration for Next.js apps.
• Render - hosts the backend FastAPI server. Free tier has 512MB RAM which caused memory issues with concurrent Playwright browsers - addressed with memory optimizations.

The backend is a FastAPI Python server.

When a request comes in, the scan pipeline starts. It runs in phases.

• Phase 1: Playwright captures the page. A real Chrome browser visits the URL, waits for the page to fully load, takes a screenshot, collects all the HTML, captures computed CSS styles for up to 150 elements, records all network requests, and closes.
• Phase 2: Parallel analyzers run. Lighthouse scores performance. The accessibility engine finds violations. The SEO analyzer checks metadata and structure. The link checker finds broken links.
• Phase 3: Synchronous analyzers process the captured data. The design system analyzer looks at colors, fonts, spacing from the computed styles. The CSS health analyzer checks for inline styles and specificity problems. The image analyzer checks for missing alt text and format issues. The animation analyzer checks for reduced motion support.
• Phase 3b: Sequential Playwright passes. The responsive checker opens the page at mobile, tablet, and desktop widths. The dark mode checker looks for dark mode CSS support. These run one at a time to avoid running out of memory.
• Phase 4: Everything gets assembled into a single report object. Saved to Supabase. Returned to the frontend as JSON.

These are the principles that guided every design decision.

• Progressive disclosure. Show the summary first. Let users go deeper on what they care about. That is why the report has an overview tab before the detail tabs.
• Plain English over technical jargon. Every finding explains the problem in a sentence anyone can understand. Not error codes. Not developer speak.
• Action over observation. Every finding comes with a suggested fix. Not just what is wrong. What to do about it.
• Visual hierarchy through severity. Critical issues are red. Serious issues are orange. Moderate are yellow. Minor are gray. Your eye goes to the important things first.
• Zero friction entry. No account. No setup. Just a URL. Reducing the barrier to first use was the most important UX decision in the whole product.
• Speed as a feature. The report loads in under 30 seconds. That is a product promise. It changes how people use it - you run it on every site you touch, not just once before launch.

• Landing Page - Its job is to convert a visitor to a user. The hero gets you to paste a URL within five seconds. Everything below it - how it works, features, testimonials - exists to handle objections and build trust.
• Report Page - The core product. Six tabs. Each gives you a different lens on the website. The Overview tab is designed to be the one most people read. The detail tabs are for people who want to go deep.
• History Page - Every scan you run is saved. You can come back and compare your site over time. See if you are getting better.
• Compare Page - Run two sites side by side. Useful for comparing against a competitor or checking a redesign against the old version.
• Privacy and Terms Pages - Built so the product feels like a real product. Shows it was thought through. Builds trust.

• The product is live. Anyone can use it.
• One-click audit from a URL. No account required.
• Six audit modes. Seventeen different analyzers running behind the scenes.
• Reports saved to Supabase so you can build a history.
• Side-by-side competitor comparison.
• The product was designed and built in two weeks by one person with Claude.

• Build the shareable report link from day one. The single biggest viral feature I missed. A report you can send to a client or post on Twitter is free marketing. I did not build it and I should have.
• Do user testing earlier. I made assumptions about what non-developers need. Some of those assumptions were right. Some were not. Real user sessions would have caught the gaps faster.
• Plan for memory constraints from the start. The backend running out of memory on Render's free tier was a problem I hit at deployment. If I had thought about it during architecture, I would have built the sequential browser execution pattern from the beginning instead of adding it as a fix.
• Build the email report export earlier. Users want to save and share their audit results. A PDF or email report would have added real value and I kept pushing it to later.

• You do not need a big team to build a real product. You need a clear problem, a clear solution, and the right tools.
• The hardest part of building a tool like this is not the code. It is making complex information feel simple. That is a design problem, not a technical one.
• Speed is a feature. Not just performance speed. Decision speed. Build speed. Iteration speed. The faster you move, the faster you learn what matters.