Why Claude? How we choose our AI tools.
Claude, GPT, Gemini and the rest. Why PerformanSite doesn't tie itself to a single AI, what we look for in each kind of task, and why most of our work happens in the Claude ecosystem.
Keeping up with the race between AI tools has become a job in itself. One model ships a new version, another starts doing better at certain tasks. A choice that made sense a few months ago may not hold up as well today.
For us, the question isn't which model is more popular. It's which one does the job in front of us better, under what conditions, and how far we can trust the result.
At PerformanSite we use Claude, GPT and Gemini. But in our day-to-day development work, and in the design of the analysis systems we're building, Claude is where most of the weight sits.
Here's why.
01We start by defining the problem
One kind of information isn't enough to make decisions about a website.
If we want to know how fast a page loads, we need a tool like Lighthouse. If we want to find problems in the HTML, we need to read the code. Judging whether a brand explains itself clearly is a different job altogether.
That last part is where AI models really earn their place: comparing information from different sources, spotting inconsistencies, explaining complex findings and thinking through possible fixes.
But that doesn't mean handing everything over to AI.
Measurement is the job of a measuring tool. The model helps us work out what the measurement might mean.
Keeping that line clear matters more than the name of the model we happen to use.
02Why mostly Claude?
The main reason we prefer Claude is that it fits the way we work.
When we build software, we're not just asking for a single function. We also need to understand why the existing code was built the way it was, what else a change might affect, and which decisions will add maintenance cost later on.
We especially like using Claude for code review, working with documentation, discussing technical decisions and in-depth analysis.
The other reason is the tooling ecosystem Anthropic has built around it.
Technologies like Claude Code, tool use through the API and the Model Context Protocol (MCP) make it possible to move AI beyond a question-and-answer box and connect it to real software workflows.
That matters to us, because we want the analysis tools we build to do more than generate reports. When needed, they should be able to exchange data with other tools.
That said, we don't claim Claude is the best model at everything. A claim like that only means something once you compare tasks, test conditions and results.
03Where do GPT and Gemini fit?
Leaning on one model doesn't mean shutting the others out.
We use GPT models to weigh up different approaches, compare drafts and get a second opinion on specific development problems.
Gemini also stays in our toolkit for research, for working through different kinds of content and for alternative assessments.
Sometimes we give the same problem to more than one model and compare the results. One model may catch a detail another missed. Sometimes they all make the same mistake.
So even three models giving the same answer isn't proof that the answer is right.
Models can help check each other. They don't remove the responsibility of verifying the facts.
04What can AI do when analysing a website?
Let's take a concrete example.
A company's website may be technically fast, yet the homepage doesn't make it clear what they sell. The service pages contradict each other. An important piece of information doesn't show up on mobile. An AI-powered answer engine links the brand to a completely different line of business.
These are all different problems.
In the approach we're developing, we first collect what can be observed: page structure, technical measurements, accessible content, screenshots and, where it makes sense, visibility tests.
Language models can then be used to assess that data.
For example, we can have Claude review a site's technical measurements, content structure and visual findings together, and work through questions like these:
- Do the brand's different pages support each other properly?
- Is the key information visitors see also clear in the page's technical structure?
- Which problems can be measured directly, and which call for interpretation?
- Where does it make the most sense to start improving?
The goal isn't to invent a new score. It's to make better decisions from the data we already have.
We're working on turning parts of this analysis process into software tools. Using AI in our daily work is not the same as every feature we build running on a model API today. When we talk about our products, we'll keep that distinction clear.
05Why MCP interests us
MCP is an open protocol that lets different applications offer data and tools to AI systems.
For us, the benefit is very practical.
Imagine an analysis tool that holds your site's technical measurements, past audits and known issues. Instead of copying reports over and over to use them in another AI tool, you can let that tool access the data it's authorised to see directly.
That's the setup we want to work towards.
By making PerformanSite's analysis tools available through an MCP server, we aim to let MCP-compatible clients such as Claude work with real audit results.
MCP isn't an AI model in itself. It's the connection between the tools a model can use and the data sources behind them.
So the value of an MCP connection shouldn't be measured by how many tools it offers, but by how useful those tools actually are.
06We have no fixed "best model"
Using mostly Claude today doesn't mean we'll use Claude for everything tomorrow.
When a model changes, when its cost or behaviour shifts, or when another model becomes a better fit for a particular task, we can revisit our choice.
That's why we try, wherever possible, to keep three things separate: the data we collect, the model that processes it, and the method we use to verify the model's output.
Keeping them apart makes it easier to build without becoming dependent on a single provider's product decisions.
It also helps clients understand what they're getting. Knowing which part of a report is real measurement and which part is model interpretation is part of being able to read the report at all.
07Final word
We don't give every job to Claude because we like Claude. We spend more time in the Claude ecosystem because it's useful in so much of our work.
We use GPT and Gemini for exactly the same reason.
What PerformanSite cares about hasn't changed: web systems that are fast, clear, easy to find and easy to build on.
What has changed are the tools we have for examining and building them.
We don't want to leave the decisions behind a good website to AI. We want to use AI to make those decisions better.
08Frequently asked questions
Which AI models does PerformanSite use?+
We use Claude, GPT and Gemini. Claude carries most of the weight in our day-to-day development work and in the design of our analysis systems, while GPT and Gemini give us second opinions, comparisons and research support.
Why mostly Claude?+
It fits the way we work on code review, documentation, technical decisions and in-depth analysis. Tools like Claude Code and MCP also make it easier to connect AI to real software workflows. That doesn't mean Claude is the best model at everything.
Does AI decide the results of a site analysis?+
No. Measurements such as speed and technical structure come from measuring tools like Lighthouse. AI helps compare that data, spot inconsistencies and weigh priorities. We keep clear which parts of a report are measurement and which are interpretation.
If several models give the same answer, does that make it right?+
Not on its own. Models can help check each other, but they can all make the same mistake. The responsibility to verify the facts remains.
What is MCP?+
The Model Context Protocol is an open protocol that lets applications offer data and tools to AI systems. It isn't a model itself; it's the connection between the tools a model can use and the data sources behind them.
Could you switch to another model in the future?+
Yes. If a model's cost or behaviour changes, or another model becomes a better fit for a task, we revisit our choice. That's why we keep the data, the model and the verification method separate.