Why Didn't They Buy?

Your website gets visitors. What happens before they leave?

Visit Website
August 30, 2026 I Built a Tool to Answer One Question: Why Didn’t They Buy?

I've spent a lot of time building websites and web applications.

And over time, I kept noticing something that bothered me.

A website can look great.

It can be fast, responsive, technically solid, and well-designed.

It can even have traffic.

But people still leave without buying, signing up, booking, contacting, or taking whatever action the business actually wants.

And when that happens, the usual advice is pretty generic:

"Improve your UX."

"Make your CTA clearer."

"Improve your copy."

"Build more trust."

"Optimize your conversion rate."

But none of that really answers the question I kept thinking about:

Why didn't they buy?

That's where this project started.


The idea

I wanted to build something that could look at a website from the perspective of a potential customer.

Not just ask:

Is this website technically good?

But:

Do I understand what this business does?

Do I understand who it's for?

Do I understand why I should care?

Do I trust it?

Do I know what to do next?

Is anything making me hesitate?

Is the path from arriving on the website to taking action unnecessarily difficult?

So I started building Why Didn't They Buy?

The idea was simple:

Find the friction that might be stopping visitors from converting.


V1 — Starting with a simple analyzer

The first version was much simpler.

The goal was mainly to prove that a website could be automatically analyzed and that the results could be useful.

But I quickly ran into a problem.

It's easy to generate a huge list of things that could be improved.

It's much harder to determine which things actually matter.

A report with 30 recommendations isn't necessarily useful.

If everything is marked as important, nothing is actually important.

That became one of the biggest problems I wanted to solve.


V2 — Making the analysis deeper

V2 became a much more serious version of the idea.

Instead of just analyzing one page and producing generic suggestions, I wanted the system to understand the website as a whole.

The analysis pipeline became something closer to:

Audit → Crawl → Understand → Analyze → Validate → Score → Report

The system started looking at:

  • multiple pages

  • page types

  • business type

  • target audience

  • business model

  • offer

  • value proposition

  • conversion goals

  • customer journey

  • CTAs

  • trust signals

  • conversion friction

  • mobile experience

  • technical issues

  • consistency across pages

One thing became particularly important to me:

Evidence.

I didn't want the AI to simply look at a website and say:

"Your website needs more trust."

I wanted to know:

Why?

What did it actually see?

Which page?

Which element?

What evidence led to the conclusion?

That pushed the product toward an evidence-based analysis system rather than simply putting an AI chatbot on top of a website crawler.


V3 — Turning it into an actual product

V3 was where the project started feeling like a real SaaS rather than a technical experiment.

The system became much more structured around understanding the business and its intended conversion goal before analyzing the website.

The philosophy became:

Don't guess first. Understand first.

The analyzer crawls the website, gathers evidence, identifies the business and conversion context, performs deterministic analysis, uses AI where contextual reasoning is useful, validates the findings, and produces a Conversion Readiness score and report.

But V3 also taught me something important.

Website scoring is hard.

I tested my own product against another website analysis product and got very different scores.

That made me stop and think.

If I tell someone:

"Your website is 54/100."

I need to be able to explain why.

I don't want the score to be a random number produced by an AI model.

I want it to be grounded in evidence, consistent, explainable and useful.

That became one of the core principles of the project.


V4 — From diagnosis to actually helping people fix things

V4 is now built and deployed.

This was the biggest evolution of the product so far.

I didn't want V4 to simply add more checks or generate longer reports.

I wanted to change what the product actually does for the user.

The philosophy became:

Diagnose → Prioritize → Fix → Measure → Re-analyze

Instead of giving someone a giant list of problems, the product focuses on:

What should I fix first?

The system prioritizes findings based on things like:

  • potential conversion impact

  • confidence

  • evidence strength

  • relevance to the conversion goal

  • affected parts of the customer journey

  • effort required

So instead of:

"Here are 27 things you could improve."

the experience becomes:

Fix these first.

1. Primary conversion path

High impact. Low effort.

2. Offer clarity

High impact.

3. Trust at the decision point

High impact.

The idea is to make the report something a business owner can actually use.


It also became more actionable

For important findings, V4 can move beyond:

"Your CTA isn't ideal."

toward:

What we found

The primary CTA is vague.

Why it matters

A first-time visitor may not understand what happens after clicking.

What to test

Use a CTA that clearly communicates the next action and aligns with the detected conversion goal.

The goal isn't to pretend that the recommendation guarantees more sales.

It's to give the user a clear, testable next step.


The buyer perspective

Another part of V4 is looking at the website through the eyes of a first-time visitor.

Questions like:

  • What is this?

  • Is this for me?

  • Why should I care?

  • Why should I trust you?

  • What does it cost?

  • What happens next?

  • Why should I choose you?

  • What risk am I taking?

  • What proof do you have?

  • What should I do now?

A website can technically answer these questions somewhere.

But if the visitor has to hunt for the answers, that's still a problem.

That's the kind of friction I'm interested in.


The part I really wanted: Fix → Re-scan

This is probably the direction I'm most excited about.

A traditional audit usually ends with a PDF.

I don't want this product to end there.

Imagine:

Before

Conversion Readiness:

54/100

The primary conversion path has several issues.

The business changes the website.

After

Conversion Readiness:

72/100

+18 points

3 issues improved.

2 issues remain.

1 new issue detected.

That creates a loop:

Analyze → Change → Re-analyze → Compare → Improve

The score is not supposed to represent actual conversion rate.

It's a diagnostic measurement of the website's conversion readiness.

That's an important distinction.


V4 also introduced the idea of experiments

Instead of pretending we know exactly what will increase conversions, the system can frame recommendations as hypotheses.

For example:

Hypothesis

A more specific CTA may reduce uncertainty.

Current

"Learn More"

Test

"See Pricing"

Measure

CTA engagement and downstream conversion.

That's much more honest than telling someone:

"Change this and your conversion rate will increase 30%."

I don't want to make promises the data can't support.


Accuracy became just as important as features

One of the biggest things I've learned while building this is that an analyzer can be impressive and still be wrong.

That's dangerous.

If a website has intentionally chosen not to display pricing because every customer gets a custom quote, the system shouldn't automatically say:

"Missing pricing!"

It should understand the context.

Similarly, if a website has several legitimate conversion paths, multiple CTAs aren't automatically a problem.

This is why V4 puts a lot of emphasis on:

  • evidence

  • confidence

  • validation

  • false-positive testing

  • false-negative testing

  • repeatability

  • AI hallucination testing

  • prompt-injection protection

I would rather have the system say:

"This cannot be determined from the available evidence."

than confidently make something up.


And now comes the difficult part

V4 is done.

It's built.

It's deployed.

The technology exists.

And honestly, this is where things get more interesting.

Because now I need to find out whether people actually want it.

Building the product was one challenge.

Getting someone to care about it is another.


The business question I'm trying to answer now

Will someone enter their website?

Will they trust the diagnosis?

Will they find the results useful?

Will they actually fix something?

Will they pay for the full report?

Will they come back after making changes?

Would an agency use this for its clients?

Those are the questions I can't answer by writing more code.

I need real users.


What I'm focusing on now

I'm not planning to immediately jump into V5 and keep adding features.

I want to validate V4 first.

I'm interested in watching the entire journey:

Visitor

Free scan

Sees diagnosis

Understands the problem

Wants the full report

Pays

Makes changes

Re-analyzes

Sees improvement

That funnel will tell me much more than another hundred features.


The bigger vision

I don't want Why Didn't They Buy? to become another generic AI website auditor.

There are already plenty of those.

The direction I want to own is much narrower:

Conversion intelligence.

Not:

"Here are some things wrong with your website."

But:

"Here is what might be stopping your visitors from taking action, here is what matters most, here is what you can do about it, and here is what changed after you fixed it."

Eventually, I can see this becoming useful not only for individual businesses, but also for agencies and consultants managing multiple websites.

But I'm deliberately not trying to build everything at once.


What I've learned building it

The biggest lesson so far is that building the technology is only half the job.

The harder part is knowing whether you're solving a problem people actually care enough about to pay for.

I've also learned that adding more AI doesn't automatically make a product better.

Sometimes the better answer is a deterministic rule.

Sometimes it's evidence.

Sometimes it's simply telling the user:

"We don't have enough information to know."

And sometimes the best product feature isn't another analysis.

It's helping someone actually do something with the analysis they already have.


Where I am today

Why Didn't They Buy? V4 is live.

The core system is built.

The next stage isn't about proving that I can build another version.

It's about proving that this solves a real problem.

So now I'm looking for people willing to actually put their websites through it.

Founders.

Small businesses.

SaaS companies.

E-commerce businesses.

Agencies.

Anyone who has ever looked at their website analytics and thought:

"Why are people visiting… but not buying?"

That's exactly the question I'm trying to answer.

And now I get to find out whether anyone actually wants the answer.

3 Comments

  1. 1
    The shift from “build another analyzer” to validating whether people actually act on the diagnosis is the interesting part. Curious which step of the funnel you expect to be hardest to prove first: trust the diagnosis, pay for it, or come back after making changes.
    1. 1
      Honestly, I think **trusting the diagnosis will be the hardest one to prove first**. If someone doesn't believe the analysis is accurate or relevant to their specific business, there's no reason for them to pay or come back. So my first goal is to get real users to tell me, “Yes, this is actually what I’m struggling with.” Then I can worry about optimizing the paid conversion and retention. The interesting part will be seeing whether those three things actually follow each other: **trust → action → return.**
      1. 1
        That makes sense. Trust is the right first hurdle to prove before interpreting payment or retention as meaningful signals.

About

Why Didn’t They Buy? helps you understand why visitors leave your website without taking action. It finds the friction, shows what’s wrong, and tells you what to fix first.