SaaS build notes

How I Built an AI SEO Platform Without Ahrefs

By Shahab Uddin, published June 16, 2026, 9 minute read

InstantSEOScan is an AI SEO audit platform built with Next.js, PostgreSQL, Prisma, DeepSeek AI, and Vercel. It has more than 125 indexed pages and has generated over 90,000 Google Search Console impressions.

The unusual product constraint is simple: it does not use Ahrefs, SEMrush, or another third-party SEO API.

That decision shaped the architecture. Instead of recreating every metric sold by a large data provider, I focused on workflows that can be produced from direct site analysis, public inputs, first-party search data, and clearly labelled AI interpretation.

Why avoid a third-party SEO API?

Large SEO data providers are useful, but building a new product entirely on top of one creates several risks:

Avoiding those APIs does not mean pretending to have their proprietary link indexes or keyword databases. It means selecting product features that can be delivered honestly with a different data model.

Start with the product boundary

The first architecture decision was not a framework. It was deciding what the platform would and would not claim.

InstantSEOScan can analyse pages, identify technical issues, organise keyword and content workflows, support Google Maps lead research, track configured positions, and use AI to explain findings. It does not label invented estimates as precise third-party traffic or backlink data.

That boundary keeps the product useful without turning uncertain data into false precision.

The application stack

The core stack is:

This is a conventional stack on purpose. The product complexity belongs in the workflows and data model, not in unusual infrastructure.

Building technical audits from direct observation

Many valuable SEO checks come directly from the target website and its responses. An audit worker can request a page, parse the document, and evaluate signals such as:

The result should store both the observation and the interpretation. For example, "canonical tag missing" is an observation. "Add a self-referencing canonical to reduce duplicate URL ambiguity" is the recommendation.

Separating those layers makes the system easier to test.

Use AI for explanation, not measurement

An AI model is good at turning structured findings into understandable priorities, drafting examples, classifying content, and suggesting next actions. It is not a reliable replacement for the crawler or database.

A safer pattern is:

  1. Collect deterministic facts in code.
  2. Validate and normalise those facts.
  3. Send a limited structured payload to the model.
  4. Ask for output in a defined format.
  5. Validate the model response.
  6. Show the source findings beside the generated explanation.

This keeps the model from inventing the technical state of a page. It can explain known data without becoming the source of truth.

Data modelling matters early

SEO products produce repeated and time-based data. A project can have many audits. An audit can have many checks. A tracked query can have observations over time. A lead source can produce duplicate businesses across collection runs.

The database needs stable ownership and history boundaries:

Exact names vary, but the principle is consistent: store raw or normalised observations separately from generated summaries. That makes regeneration, debugging, and comparison possible.

Treat background work as a product feature

Crawling, scoring, AI generation, and bulk data collection may take longer than a normal web request. The interface should not freeze while it waits.

A production workflow needs:

Even a simple implementation benefits from designing these states before the first long-running feature ships.

Programmatic content without thin pages

InstantSEOScan has more than 125 indexed pages, including over 65 SEO guides. Publishing many pages only helps when each page has a real purpose.

For scalable content, every page should have:

Changing a city or keyword inside the same shallow template is not a durable content strategy. Programmatic structure can accelerate publishing, but the page still needs enough unique value to deserve indexation.

Pricing under infrastructure constraints

When a Pro plan starts at $10 per month, every paid dependency matters. Product limits should connect to actual cost drivers such as:

The database should record usage events on the server. Hiding a button in the browser is not usage enforcement.

What I would preserve in another SEO SaaS

The strongest decisions were:

  1. Define honest product boundaries before building metrics.
  2. Keep deterministic collection separate from AI explanation.
  3. Store observations in a form that can be reprocessed.
  4. Design long-running states as part of the user experience.
  5. Publish content that demonstrates the product's domain knowledge.
  6. Keep infrastructure costs visible in plan limits.

The broader lesson

You do not need to clone a large platform to build a useful SaaS product in the same market. A smaller product can win by solving a narrower workflow, owning its core logic, explaining results clearly, and pricing around a controlled cost base.

That is the approach behind InstantSEOScan: direct analysis, structured storage, constrained AI assistance, and a product scope that does not depend on an expensive SEO data API.

See the full portfolio case study or discuss a focused SaaS MVP.