Categories
SEO

AEO vs SEO vs GEO: What Actually Changed in 2026

Key takeaway (the short answer): SEO, AEO and GEO are not three competing strategies — they’re three layers of the same job. SEO gets you found on a search results page. AEO (Answer-Engine Optimization) gets your content lifted into an AI-generated answer. GEO (Generative Engine Optimization) is used interchangeably with AEO for the same goal. What changed in 2026 is where the answer gets consumed: increasingly inside ChatGPT, Perplexity and Google AI Overviews rather than on a blue-link page. What didn’t change: you still need crawlable, credible, well-structured content. AEO/GEO extends SEO; it doesn’t replace it.


Every few years the marketing world declares an old discipline dead and crowns a new acronym. In 2026 the acronym is GEO, or AEO, and the “dead” discipline is supposedly SEO. Both claims are wrong in the usual way — oversimplified. Here’s what actually changed, what didn’t, and how to prioritize without chasing hype.

The definitions, straight

Term Full name The job it does Where the user sees the result
SEO Search Engine Optimization Rank your page in organic search results The search results page (blue links)
AEO Answer-Engine Optimization Get your content lifted into a direct answer An AI answer / featured snippet / AI Overview
GEO Generative Engine Optimization Get cited/recommended by generative AI engines Inside a ChatGPT / Perplexity / Gemini answer

Are AEO and GEO the same thing? In practice, yes. GEO emphasizes generative engines specifically; AEO is the broader “optimize to be the answer” framing that also covers featured snippets and AI Overviews. The industry uses them interchangeably, and the tactics overlap almost entirely. Don’t let anyone sell you them as two separate services.

What actually changed in 2026

1. A big share of queries never reach a results page

A rising share of searches now end without a click — the answer is delivered inline. Users increasingly ask an AI engine and act on the synthesized answer rather than visiting a page. The moment of decision moved into the answer.

2. Being #1 stopped guaranteeing the click

You can rank first and still be invisible if the AI Overview above you answers the question and cites someone else. Position is necessary but no longer sufficient.

3. Citations replaced clicks as a top-of-funnel currency

When an engine names your brand inside an answer, that’s the new impression — even without a visit. “Share-of-answer” (how often you’re cited for target prompts) became a metric worth tracking alongside rankings and clicks.

4. Corroboration got more important than any single page

Engines synthesize from sources they trust, and trust comes from consistent mentions across the web — not one perfectly-tuned page. This is why GEO is often described as ~80% authority and positioning, ~20% technical.

5. First-hand experience beat rewritten consensus

As models got better at summarizing the generic middle, the generic middle stopped getting cited. Genuine experience and specific, first-party judgment became the differentiator engines and readers reward (E-E-A-T with teeth).

What did NOT change

It’s easy to over-rotate. These fundamentals are as load-bearing as ever:

  • Crawlability and clean technical foundations. Engines still have to reach and read you. A broken sitemap or a stray noindex sinks AEO exactly like it sinks SEO.
  • Content quality and relevance. You still have to actually answer the question well.
  • Internal linking and site structure. Clusters and clean architecture still concentrate authority.
  • Intent. Understanding what the searcher actually wants was always the job — natural-language prompts just make intent more explicit.

SEO didn’t die. It became the foundation layer that AEO and GEO are built on. Skip it and the new stuff has nothing to stand on.

How to prioritize (a simple decision guide)

You don’t choose between these. You sequence them:

  1. Get the SEO foundation right first. Crawlable, fast, canonical, internally linked. Non-negotiable base.
  2. Layer AEO on top of your money pages. Direct-answer blocks, FAQs, comparison tables, schema — so engines can lift you.
  3. Invest in GEO authority for the long game. Corroboration, consistent positioning, first-party proof, distribution. This is the slow-compounding moat.

If your foundation is broken, no amount of AEO tactics will save you. If your foundation is solid but you have no answer blocks or authority, that’s where the fastest gains are.

A note on judgment (why this isn’t just tactics)

I’ve spent 18+ years running digital and performance marketing across brands like Cleartrip, Wakefit, Simpl, UNext Learning, Lendingkart, Adda52, FreeCharge and Times Internet. The through-line across every platform shift — desktop to mobile, organic to paid, and now search to answer engines — is the same: the channel changes, the discipline doesn’t. Teams that treated each shift as “throw out everything” lost. Teams that asked “what’s genuinely new and what’s still true” won. AEO/GEO is exactly that kind of shift. Treat it as an extension of a solid foundation, not a replacement for one.

FAQ

Is SEO dead in 2026? No. Search volume has declined and answers moved into AI engines, but the technical foundations of SEO — crawlability, structure, relevance, internal linking — are exactly what make AEO/GEO possible. SEO is the base layer, not a dead one.

What’s the difference between AEO and GEO? Very little in practice. GEO stresses generative engines (ChatGPT, Perplexity, Gemini); AEO is the broader “be the answer” framing that also includes AI Overviews and featured snippets. Same goal, overlapping tactics — treat them as one discipline.

Should I stop doing SEO and only do GEO? No — that’s the trap. GEO without an SEO foundation has nothing to stand on. Do SEO first, layer AEO on your key pages, then invest in GEO authority over time.

How do I measure AEO/GEO success? Track share-of-answer (how often you’re cited for target prompts and next to whom), your citation footprint across the web, and downstream inquiry/click lift — alongside your existing rankings and organic traffic.

Where do I start? With an honest audit of whether engines can currently find, extract and trust you. (See the AI Visibility Audit: 12 Checks I Run Before Any Engagement.)


Related reading


Not sure which layer your brand is losing on? That’s exactly what a discovery-first audit answers — no canned plan, just a clear read of SEO, AEO and GEO gaps. Start a project inquiry →

Categories
SEO

The AI Visibility Audit: 12 Checks I Run Before Any Engagement

Key takeaway (the short answer): Before I promise any result on an engagement, I run a 12-point AI Visibility Audit to see whether AI answer engines can find, extract, and trust their brand. The checks fall into three groups: Retrievability (can engines reach and read you), Extractability (can they lift a clean answer), and Authority (do they trust and cite you). Work through the 12 checks below and you’ll know exactly where you’re losing AI visibility — before spending a rupee on content.


Most marketing engagements start with a canned 90-day plan. Founders are right to screen that out — you can’t prescribe before you diagnose. So I don’t. Every engagement starts with a discovery audit, and in 2026 a big part of that is AI visibility: whether ChatGPT, Perplexity, Gemini and Google’s AI Overviews can surface your brand when it matters.

This is the actual checklist. Twelve checks, three categories, each with what I look for and why it matters. Run it on your own site this week.

How to use this: For each check, score yourself Pass / Partial / Fail. Anything below a Pass is a specific, fixable gap. Tally the categories at the end — your weakest category is where AI visibility is leaking fastest.

Part A — Retrievability (can engines find and read you?)

Check 1 — Are your key pages crawlable and indexable?

Engines can’t cite what they can’t reach. Confirm no accidental noindex, no blocked paths in robots, and that your most important pages return clean 200s. A single stray noindex on a go-live can erase months of work — I’ve seen it happen on launches, and it’s the first thing I verify.

Check 2 — Is your content in a live sitemap?

A current, submitted XML sitemap is the fastest path for engines to discover new and updated pages. Missing or stale sitemaps slow discovery to a crawl.

Check 3 — Does the page load fast and render without JavaScript gymnastics?

If core content only appears after heavy JavaScript rendering, some crawlers miss it. Server-rendered or statically-present text is safest. Slow TTFB also depresses crawl frequency.

Check 4 — Is there one canonical version of each page?

Duplicate or self-conflicting canonicals confuse retrieval and split authority. Every important page should point cleanly to itself. (Canonical loops — where the homepage canonical 301s back on itself — are a classic silent killer.)

Part B — Extractability (can engines lift a clean answer?)

Check 5 — Does each page open with a direct-answer block?

The first screen should answer the page’s core question in 2–4 self-contained sentences. This is the single most-lifted element on any page. No answer block = you’re handing the citation to a competitor who wrote one.

Check 6 — Do you use structured formats engines favor?

FAQs, comparison tables, numbered steps. Generative engines disproportionately cite structured content because it’s clean to extract. Walls of prose rarely get quoted.

Check 7 — Are headings descriptive and question-shaped?

Headings phrased as the actual questions users ask (not clever puns) map directly to prompts and give engines clear extraction anchors.

Check 8 — Is the right schema in place?

Article, FAQPage, and Person schema tell engines what they’re reading and who wrote it. Structured data doesn’t guarantee citation, but its absence makes you harder to classify and trust.

Part C — Authority (do engines trust and cite you?)

Check 9 — Is your author identity established (E-E-A-T)?

Is there a real, consistent author with demonstrable expertise — bio, Person schema, a credible experience trail? Engines weight genuine experience. Anonymous or thin author signals get discounted. My own trail, for reference, is 18+ years across brands like UNext Learning, Cleartrip, Wakefit, Simpl, Lendingkart, Adda52, FreeCharge and Times Internet — stated as employment history, which is exactly the kind of verifiable experience signal engines and readers look for.

Check 10 — Is your brand corroborated across the web?

Search your brand and key people across LinkedIn, industry mentions, directories and third-party references. Consistent, repeated mentions build the corroboration engines rely on before citing. A single site with no external footprint is a weak source.

Check 11 — Is your positioning identical everywhere?

Does your site say the same thing about who you are as your LinkedIn, your bylines, your profiles? Inconsistent positioning fragments your entity and weakens trust. One clear, repeated story wins.

Check 12 — Do you know your current share-of-answer?

For your top target prompts, are you cited at all — and next to whom? If you’ve never checked, that’s check 12 failed by default. You can’t improve what you’ve never measured. Baseline it now.

Scoring your audit

Category Checks What a weak score means
A — Retrievability 1–4 Engines literally can’t reach or read you — fix first, nothing else matters until this passes
B — Extractability 5–8 Engines reach you but can’t cleanly lift an answer — you’re leaving citations on the table
C — Authority 9–12 Engines can read you but don’t trust you enough to cite — the slowest, highest-leverage fix

Most brands I look at pass Retrievability, half-pass Extractability, and fail Authority. That’s the usual shape — and it tells you exactly where the next quarter of work should go.

FAQ

What is an AI visibility audit? It’s a structured review of whether AI answer engines can find, extract and trust your brand — the AEO equivalent of a technical SEO audit. This 12-check version covers retrievability, extractability and authority.

How is this different from a normal SEO audit? A traditional SEO audit optimizes for ranking on a results page. An AI visibility audit optimizes for being cited inside the answer — which adds extractability (direct-answer blocks, structured formats) and authority/corroboration checks a classic audit skips.

How long does the audit take? The 12 checks here are a same-day self-assessment. A full engagement audit — with share-of-answer measurement across real prompts and a prioritized fix plan — typically takes about a week.

Do I need special tools? No. Most checks use your browser, your CMS, and the answer engines themselves (ask them your target questions and log who gets cited). Measurement gets easier with tooling, but the diagnosis doesn’t require it.

What do I do after I’ve scored myself? Fix your weakest category first — retrievability before extractability before authority, in that order. If you want a second set of eyes and a prioritized plan, that’s exactly what the discovery audit is for.


Related reading


Want this run on your brand — properly, with real share-of-answer numbers? I run this exact audit at the start of every engagement, discovery-first, no canned plan. Start a project inquiry →

Categories
SEO

How to Get Your Brand Cited by ChatGPT & Perplexity (AEO Playbook)

Key takeaway (the short answer): To get cited by ChatGPT, Perplexity and Google AI Overviews, you have to make your brand quotable and corroborated. That means (1) publishing clear, extractable answers to the exact questions buyers ask, (2) structuring pages so an engine can lift them — direct-answer blocks, FAQs, comparison tables, clean headings — and (3) building enough consistent mentions across the web that the model trusts you as a source. AI visibility is roughly 80% authority and positioning, 20% technical. This playbook walks the exact seven steps I use to get there.


For fifteen years the game was “rank #1 on Google.” In 2026 a growing share of buyers never see a results page at all — they ask ChatGPT, Perplexity, Gemini or Google’s AI Overview and act on the answer. A rising share of searches now end without a click — the answer is delivered on the spot — and the queries that still send traffic are increasingly answered for the user, with two or three brands cited inline.

If your brand isn’t one of those citations, you’re invisible at the exact moment of decision. Answer-Engine Optimization (AEO) — sometimes called GEO, Generative Engine Optimization — is how you fix that. Here’s the playbook.

First, what “getting cited” actually means

When someone asks Perplexity “who’s a good fractional digital marketing consultant for a fintech,” the engine does three things:

  1. Retrieves candidate sources from its index and live web search.
  2. Synthesizes an answer from the most relevant, most corroborated ones.
  3. Cites the handful it leaned on — often with a linked footnote or a named brand.

You win citations by being easy to retrieve, easy to extract, and hard to doubt. Everything below serves one of those three goals.

The 7-step AEO playbook

Step 1 — Map the questions, not just the keywords

Answer engines are queried in natural language, so your unit of work is a question, not a keyword string. List the real questions a buyer asks on the path to hiring you or buying your product. For a fractional consultant that’s things like: “How do I know if I need SEO or paid?”, “What does a marketing audit actually check?”, “AEO vs SEO — what changed?”

Group them into a tight cluster around one niche. Depth beats breadth: engines reward a site that is demonstrably the authority on a narrow topic over one that covers everything shallowly.

Step 2 — Lead every page with a direct-answer block

Put a 2–4 sentence answer to the page’s core question in the first screen — before the throat-clearing. This is the single highest-leverage AEO move, because engines preferentially lift concise, self-contained answers that sit near the top of a page. The block you’re reading at the top of this post is exactly that pattern.

Write it so it stands alone: if an engine quotes only those sentences, they should still be true, useful, and attributable to you.

Step 3 — Structure content the way engines parse it

Generative engines disproportionately cite structured formats — they’re easier to extract cleanly. Use:

  • Numbered steps for processes (like this list).
  • Comparison tables for “X vs Y” decisions.
  • FAQ sections with the literal question as a heading and a short answer beneath.
  • Descriptive H2/H3 headings phrased as questions or clear claims, not clever puns.
Content format Why engines favor it
Direct-answer block Extractable, self-contained, high on the page
FAQ (Q as heading) Maps 1:1 to how users phrase prompts
Comparison table Clean structured data for “vs” and “best” queries
Numbered steps Unambiguous sequence, easy to quote as a list
Long walls of prose Hard to extract → rarely lifted verbatim

Step 4 — Add the schema that tells engines what they’re reading

Machine-readable structured data helps engines classify and trust your content. At minimum, mark up:

  • Article — for the post itself (author, date, headline).
  • FAQPage — for your FAQ sections.
  • Person — establishing the author’s identity and expertise (E-E-A-T).

On this site Yoast is live and handles most of this; the schema pass is a coordinated handoff to SEO, but the content has to be structured first for the schema to have anything to describe.

Step 5 — Prove first-hand experience (E-E-A-T is the moat)

Engines — and the humans tuning them — increasingly weight genuine experience over rewritten consensus. Generic listicles get filtered; first-party judgment gets cited. So write from what you’ve actually done.

My own credibility spine is 18+ years running digital and performance marketing at Indian consumer-internet brands — Head of Digital Marketing at UNext Learning and at Cleartrip, VP roles at Wakefit, Simpl and Lendingkart, CDMO at Adda52, and earlier marketing roles at FreeCharge and Times Internet. That’s experience, stated as an employment timeline — not borrowed testimonials. When you write, anchor claims in what you personally observed: the campaign you ran, the audit you did, the thing that broke. That specificity is exactly what engines can’t synthesize from anyone else, so it’s exactly what gets attributed to you.

Step 6 — Build corroboration across the web

This is the 80% nobody wants to hear, because it’s not a page edit. Answer engines cite sources they’ve seen corroborated — a brand that shows up consistently across your own site, LinkedIn, guest mentions, directories and third-party references is one the model trusts. A single perfectly-optimized page with zero external footprint rarely wins.

Practical moves: repurpose each pillar post into a native LinkedIn post (put the link in the first comment to protect reach), get named in relevant industry pieces, keep your bio and positioning identical everywhere so the entity is unambiguous. Distribution and AEO aren’t separate tracks — the same mentions that drive reach are inputs to whether an engine cites you.

Step 7 — Measure share-of-answer, then iterate

You can’t manage what you don’t watch. Track:

  • Share-of-answer: for your target prompts, how often are you cited, and alongside whom? Ask the engines directly and log it.
  • Citation footprint: where you’re being referenced across the web.
  • Downstream: organic clicks to service pages and inquiry-form submissions attributable to the cluster.

Baseline it now, before you publish more, so lift is measurable against a real starting line. Then feed what you learn back into Step 1.

Common mistakes that keep brands uncited

  • Optimizing for keywords, not questions. Engines think in intents.
  • Burying the answer. If the model has to dig, it moves on to a page that didn’t make it dig.
  • Publishing without distribution. No corroboration, no citation.
  • Thin coverage everywhere. Niche authority beats broad mediocrity every time.
  • Fabricated proof. Invented testimonials are both an integrity failure and an E-E-A-T liability — real experience is the asset.

FAQ

What is Answer-Engine Optimization (AEO)? AEO is the practice of structuring your content and building your brand’s web presence so that AI answer engines — ChatGPT, Perplexity, Google AI Overviews, Gemini, Claude — cite and recommend you when users ask relevant questions. It extends SEO into the generative-search era.

Is AEO the same as GEO? Practically, yes — GEO (Generative Engine Optimization) and AEO are used interchangeably for the same goal: earning visibility inside AI-generated answers. (For the full breakdown, see AEO vs SEO vs GEO: What Actually Changed in 2026.)

How long does it take to get cited? The on-page work (direct-answer blocks, structure, schema) can be done in days and often surfaces in weeks. The corroboration and authority layer — the part that actually moves the needle — compounds over months. It’s a flywheel, not a switch.

Do I still need traditional SEO? Yes. SEO remains the foundation; AEO extends it. The technical fundamentals — crawlability, clean structure, internal linking — are what let engines retrieve you in the first place.

Can I do this myself or do I need help? The framework here is genuinely DIY-able. Where teams usually get stuck is judgment: which niche to own, which questions actually convert, and reading share-of-answer honestly. That’s the discovery-first work worth getting a second set of eyes on.


Related reading


Want to know where your brand actually stands in AI answers today? I run a structured AI Visibility Audit before any engagement — no canned 90-day plan, just an honest read of what’s working and what isn’t. Start a project inquiry →

Categories
AI Product / Blog

Building a Real Product With the Claude API: What I Actually Learned

I want to write the post I wish had existed before I started.

Most writing about building with Claude API or any LLM API falls into one of two categories: breathless hype about how AI will change everything, or step-by-step tutorials that stop right where the real problems begin. Neither of those helped me when I was three weeks into an integration that wasn’t working the way I expected.

This is the honest account. The product, the decisions, the things that broke, and what I would do differently.

The Problem

The brand was a mid-sized media company — a WordPress-based publication with a small editorial team producing several long-form articles a week. The bottleneck wasn’t writing. It was briefing.

Before any article was written, an editor had to produce a brief: the angle, the key questions to answer, the competing coverage to be aware of, the suggested sources. For a team producing 15–20 pieces a week, that briefing work was consuming two to three hours a day of a senior editor’s time. Time they would rather have spent editing the actual work.

They had tried to solve this before. Templates. A shared Google Doc with a prompt they’d paste into ChatGPT. A Notion database that nobody updated. None of it stuck because none of it lived where the editors actually worked — inside the WordPress backend where articles were created.

The ask was straightforward: build something inside WordPress that would help editors generate first-draft briefs based on a working title, without making them context-switch to another tool.

Why Claude API

I chose Claude for three reasons, none of which were loyalty to a brand.

First, the output quality on structured, context-rich editorial tasks was consistently better in my testing. I ran the same brief-generation prompt through three APIs. Claude’s output required less cleanup and followed the format I specified more reliably.

Second, the context window. Editorial briefs benefit from being able to include the article title, a category taxonomy, related articles already published, and sometimes a rough notes dump from the commissioning editor. That’s a lot of input. I needed room to work.

Third, I wanted streaming support. I already suspected the latency problem was going to be my biggest UX challenge, and I needed an API that would let me stream tokens to the frontend. Claude’s API does this cleanly.

The Design Decisions That Mattered

Decision 1: Where in the workflow to live

The first prototype surfaced the feature as a standalone panel in the WordPress sidebar — a “Generate Brief” button that appeared on every new post. This was wrong.

Editors told me they didn’t want it at post creation. They wanted it earlier — during the commissioning stage, before an article was even assigned. The feature was solving the right problem in the wrong place in the workflow.

I moved it upstream. The revised version lived on the editorial planning board (a custom post type used for commissioning), not on the article post itself. Usage tripled after that change.

The lesson has nothing to do with AI: build the feature where the workflow actually lives, not where it’s technically convenient to add it.

Decision 2: Streaming vs. waiting

The brief generation call takes between three and six seconds depending on the complexity of the input. I tested three approaches to making that wait bearable.

Option A was a spinner with a “Generating your brief…” message. Users clicked the button again. Every time. They assumed it had frozen.

Option B was a skeleton loading state — placeholder lines that gave a sense of the structure being built. Better, but users still checked their email during the wait and lost context when it finished.

Option C was streaming. Text appeared token by token, typewriter-style, from the moment the first tokens arrived from the API. Editors watched it build. They stayed engaged. A few told me they found themselves reading as it generated and already had notes forming before it finished.

Streaming won decisively and it wasn’t close. If you are building with Claude API and your response time is over two seconds, streaming is not optional. It changes the product.

Decision 3: Prompt architecture

The first prompt I shipped was entirely engineered by me. It was structured, detailed, and almost completely useless to the people using it.

The briefs it produced were too long, too generic, and structured in a way that matched how I thought about editorial briefs, not how the editors did. I had written a good prompt for myself.

I fixed this by sitting down with the senior editor for ninety minutes and asking her to walk me through how she actually wrote a brief when she did it manually. Not the ideal version — the real version, with all the shortcuts and priority calls.

That conversation changed the prompt entirely. The structure shortened. The tone changed. References to competing coverage moved from a late-document appendix (where I had put them) to the second element (where she always put them). The “suggested questions” section that I thought was the most valuable part got cut — she never used it when briefing writers.

The best prompt engineering I did on this project happened in a conversation that had nothing to do with prompts.

What Didn’t Work

The “just regenerate” problem. Because regeneration was one button click, editors quickly developed a habit of clicking it multiple times and picking the version they liked best. This sounds fine until you realise that each regeneration is a different interpretation of the same input — and the act of choosing between them became a task of its own. Briefs that had previously taken one generation started requiring three or four.

I added a light friction: a “refine” mode where editors could note what they wanted to change before regenerating, rather than blank regenerating. This produced better briefs, reduced regeneration volume by about 60%, and — unexpectedly — produced briefs that editors felt more ownership over because their judgment was part of them.

Context window mismanagement (early versions). In the first builds I was including everything: article title, category, recent articles in the same category, SEO keywords, any commissioning notes. The outputs were comprehensive and wandered. I was giving the model so much that it tried to address all of it.

I progressively restricted the input until I found the minimum context that produced a useful output. Ironically, less context produced more focused briefs. The model needs direction, not information dumps.

Error state design. API calls fail. Rate limits happen. Network blips happen. My first error handling was a red toast notification that disappeared in three seconds. Editors didn’t see it, clicked the button again, got another failure, and assumed the feature was broken.

Error states need to be persistent, clear, and tell the user what to do next — not just that something went wrong.

Five Things I Would Tell Myself Before Starting

1. Solve the UX for latency before you write a single prompt. Decide whether you’re streaming or not, and design the loading state first. Everything else follows from that decision. A fast, bad-output feature has a path to good. A slow, bad-output feature gets abandoned.

2. Your first prompt is for you, not for the user. Don’t ship until you’ve watched a real user interact with the output and told you what’s wrong with it. The gap between what you think is useful and what is actually useful will surprise you every time.

3. The integration is the easy part. The Claude API is well-documented, straightforward to authenticate, and reasonably predictable. The hard work is product thinking: where does this live, what does it replace, what friction does it add, what friction does it remove.

4. Build for the unhappy path from the start. Errors, timeouts, rate limits, and malformed outputs are not edge cases. They’re regular occurrences at scale. Design your error states with the same care you design your success states.

5. Less context is often more. Give the model what it needs to do the specific job, not everything you think might be relevant. Specificity of input produces specificity of output. Information dumps produce comprehensive wandering.

What It Looked Like at the End

The feature shipped after about six weeks of build and iteration. The senior editor who had been spending two to three hours a day on briefs now spends about forty minutes. The briefs are not perfect — she edits them every time — but they’re good enough to be a starting point rather than a blank page.

That’s a meaningful outcome. Not because of AI. Because someone understood a workflow problem well enough to build something that actually fit inside it.

Building with Claude API is accessible. The documentation is good, the API is clean, and the capability is genuinely impressive. What is not simple is building something useful with it — that requires product thinking that no API can substitute for.

If This Was Useful

I write occasionally about building AI products, consulting, and the decisions that don’t make it into tutorials. If that interests you, the newsletter is the best way to follow along — sign up below.

If you’re working on an AI integration and could use a thinking partner or a second set of eyes on the product decisions: that’s something I do.


Categories
AI Product / Blog

The Practitioner’s Guide to Building AI Products

Most AI products fail before they ship. Not because the model is wrong, not because the infrastructure is too expensive — but because the team skipped the hard thinking and went straight to building.

I’ve been building with AI since before it was the thing everyone was building with. I’ve seen the pattern repeat: smart people, real budget, genuine ambition — and a product that never quite works in the real world. This is my attempt to give you the map I wish I’d had earlier.

Why Most AI Products Fail

Here’s the uncomfortable truth: most teams treat AI as a feature before they understand the problem it’s solving.

They see what GPT-4 can do in a demo, convince themselves it applies to their use case, and start engineering before anyone has asked the hard questions. The result is an AI-shaped layer on top of a problem that either wasn’t solved by the non-AI version either, or didn’t need AI at all.

The failure modes cluster around three things:

1. Optimising for wow over utility. The demo is great. The model responds coherently, the UI is slick, the investor call goes well. Then real users arrive and the cracks show. They ask questions the model wasn’t tuned for. Edge cases multiply. The product works 80% of the time, which in most contexts is worse than a simpler tool that works 95% of the time.

2. Treating latency and reliability as engineering problems only. Your PM instinct might say “we’ll fix performance later.” In AI products, that instinct is wrong. Users form their trust relationship with an AI product in the first five interactions. A slow, inconsistent response in session one can kill retention permanently — regardless of how much better it gets in week three.

3. Ignoring the human in the loop. The best AI products I’ve worked on all had a clear model for when the AI should act, when it should ask, and when it should get out of the way entirely. Teams that never define this end up with products that either do too much autonomously (and get things wrong in ways that erode trust) or interrupt users constantly (and become annoying faster than any competitor ever could).

The Right Starting Questions

Before you write a line of code or pick a model, answer these four questions honestly:

What is the specific human task this replaces, augments, or accelerates? Not a category. A task. “AI for customer support” is not an answer. “Drafting the first response to a refund request so a human agent can review and send in under 30 seconds” is an answer. Specificity here is everything.

Where does the AI need to be right, and where can it be approximately right? AI products are probabilistic by nature. That’s fine for some use cases and catastrophic for others. A product that helps a PM draft a PRD can tolerate hallucinations that a human will catch. A product that flags compliance risks in legal contracts cannot. Know your error tolerance before you commit to a model architecture.

What does failure look like to the user? Not what does a failed API call look like — what does the user experience when the AI gets it wrong? Do they know it’s wrong? Can they correct it? Does a wrong output cascade into something worse? Map the failure experience before you design the success experience.

What does the non-AI version of this look like? If you can’t describe the manual or rule-based version, you don’t understand the problem well enough to build the AI version. This isn’t a rhetorical question — the non-AI version is often your fallback, your eval baseline, and your user’s mental model all at once.

A Practical Framework for Building AI Products

This is what I use. It isn’t academic — it’s what I’ve iterated to after shipping things that worked and things that didn’t.

Step 1: Define the unit of value

AI product management best practices usually start with user stories. I start differently: I start with the unit of value the AI produces.

For a writing assistant, is the unit a complete draft? A single sentence? A structural suggestion? For a customer service bot, is it a resolved ticket? A deflected contact? A satisfied user?

The unit of value determines your eval criteria, your success metric, and your roadmap priorities. Everything downstream from here is easier when this is sharp.

Step 2: Build the eval before the product

This is the move most teams skip, and it’s the one that saves the most time.

Before you build the product, build the thing that tells you whether the product is working. This means: a set of real (or realistic) inputs, the outputs you expect, and a scoring mechanism. It doesn’t have to be automated on day one. A spreadsheet with 50 test cases and a human grader is infinitely better than shipping and waiting for support tickets.

When the eval exists before the product, every model change, prompt change, and architecture decision has a ground truth to test against. Without it, you’re flying blind and calling it iteration.

Step 3: Design the trust boundary explicitly

Every AI product has a trust boundary: the point at which the AI’s output becomes consequential enough that a human should review it before it has effect.

Design this on purpose. Don’t let it emerge from your implementation. Some products should have the trust boundary at “never” (AI drafts, human always reviews). Some can push it to “usually” (AI acts, human reviews on request). Very few should be at “always” (AI acts autonomously, no review path).

The right answer depends on your domain, your error tolerance (see starting question #2), and your users’ existing trust in automation. The mistake is never deciding.

Step 4: Ship the smallest thing that tests the real constraint

The real constraint is almost never the model. It’s the data pipeline, the user workflow, the latency requirement, the regulatory environment, or the cost at scale.

Ship the smallest version that puts the real constraint under load. Not the real constraint as you imagine it — as it actually exists in your production environment, with your real users, doing your real task.

I’ve seen teams spend three months fine-tuning a model when the blocking issue turned out to be that users didn’t trust AI output unless it showed its reasoning — a prompt engineering fix that took two days. Build to find the real constraint fast.

Step 5: Instrument everything from day one

AI products have a data flywheel that traditional software products don’t. Every user interaction is a potential training signal, an eval case, or a trust-calibration datapoint.

But only if you collect it.

From the first production user: log inputs, log outputs, log corrections, log abandonment. Don’t wait until you have scale to care about data quality. The decisions you make about data collection in the first month determine what you can do in month six.

Common Traps (That I’ve Fallen Into Myself)

The context window trap. When the model has a large context window, it’s tempting to throw everything in and let the model figure it out. This works in demos. In production, it increases latency, increases cost, and often decreases output quality because the signal-to-noise ratio drops. Be ruthless about what goes into context.

The prompt engineering treadmill. Prompts are not a stable foundation. A prompt that works perfectly today can degrade with a model update, a change in user behaviour, or even drift in the distribution of inputs over time. Treat your prompts like code: version them, test them, review changes. If your product’s quality lives entirely in an unmarked string in your codebase, you’re one deployment away from a regression you can’t explain.

The cost model surprise. Token costs are predictable. Usage patterns are not. A feature that costs $0.02 per interaction sounds cheap until your power users hit it 300 times a day. Model your cost per user segment, not just per call — and build cost controls before you need them.

Confusing technical capability with product-market fit. The model can do it. That doesn’t mean users want it, trust it, or will pay for it. These are different questions. Capability is a necessary condition for an AI product, not a sufficient one. Keep testing the PMF assumption even when the demo is impressive.

Skipping the edge case conversation. Edge cases in AI products aren’t just technical edge cases — they’re the inputs your users will actually produce that your happy-path design didn’t anticipate. Run a structured edge case session with real users early. What’s the weirdest thing they’d try? What happens? Is it acceptable?

The Short Version

Building AI products well is a practice, not a formula. The teams that get it right share a few habits: they define specificity before they define architecture, they build evaluation infrastructure before they build product, and they treat trust as a design constraint — not an afterthought.

The teams that struggle are usually moving too fast to stop and answer the hard questions. Speed matters in product. But in AI product development, the questions you skip at the start have a way of becoming the crises you manage at the end.

Work With Me

If you’re a founder or PM building your first AI product and want a practitioner in your corner — for strategy, architecture review, or hands-on build support — let’s talk.

And if you’d rather start with the writing: I publish Ship It, a newsletter for people building with AI. Short, opinionated, no filler. Sign up here.


Categories
SEO

Google Gemini VS Chat GPT who will lose?

Just to break it down there are 2 types of searches that happen on Google

  1. Informational 
  2. Transactional

Over time a lot of Transactional (e-commerce) searches have moved from Google to Amazon or Flipkart

And now Chat GPT is eating up share in the information category and Google Gemini is a response to that 

Now I don’t know who will win in the end but I know who will definitely lose and that is content websites.

Most content websites are dependent on traffic from Google searches and then make money through ads on their platform, but with Chat GPT and Google Gemini growing share content websites can expect a huge dip in their traffic and hence revenue

Solution?

If you manage a content website, block AI bots from crawling your websites.

Categories
SEO

Is SEO Dead?

This is most frequently asked question by professionals hoping to build themselves a career in online marketing. The answer to this question is No.. SEO is not dead or dying. In fact, It is evolving every day. But, If you think there are some Quick Hacks and Tricks that someone can teach you and you will also become a pro, then you are Mistaken. SEO expertise comes with experience and not shortcuts.

Those days are long gone when People use to do a lot of so-called Black Hat SEO tricks, paid link building, pushing Keyword Stuffed Content on Multiple sites. Google is Smart enough and can figure all that. The Key to Success is Content and it always was. People forget this very basic thing while doing SEO.

If you really want to learn SEO then you should learn from those who are killing on Google Search results in whichever industry they are working in. Try to figure what have they done right, and try to reverse engineer.

Following are the few Basics of SEO:

  • Content – 70%
  • On Page Optimisation – 25%
  • Off Page Optimisation – 5%

Content

  1. Make sure you write for end users not for Bot, not what your boss likes but what the end user would want to read, just make sure your content is always fresh and constantly updated, two things are really important:
    1. Recency – when did you post the content?
    2. Frequency – how regularly do you update the content?
  2. Page Title and Meta description is very important, it tells Bot what your page is about.  The more relevant you keep it, the better. If you don’t update Meta Tags regularly, google will even start ignoring it and will pick content from your page to show it as a snippet in Google search results
  3. Avoid Copying content from other sites or duplicate content within your site.
  4. Make sure whatever you write should have a specific purpose and Target Audience.
  5. You should never have separate SEO pages. Your original site flow and content should be optimized for SEO

On Page Optimisation

  1. Make sure to make full use of H1, H2, and H3 Tags
  2. All images on the Site should be optimized for speed and should have ‘alt’ Tags
  3. Page load time is really important, in fact, is the most important thing.
  4. The site should be Responsive and Mobile Optimized. Avoid creating separate pages for mobile.
  5. Site navigation as well as internal linking, is very important.
  6. Make use of rich snippets where ever possible as well as schema tags

Off Page – is useless or at max contributes to 20% to overall SEO effort, If you get the first 2 things right, don’t worry about this.. you will do well 

There are a lot more important things that I can’t share in one article. Feel free to ask any questions and email me at email@chetansharma.me and you will get a reply back for sure.

Categories
General

11 lessons to learn from Gabbar Singh the management guru

Many of you may be aware of the legendary movie called Sholay and the equally legendary character called Gabbar Singh. Those who aren’t, I’ll quickly summarize who was Gabbar Singh. Gabbar Singh was a notorious dacoit who had spread havoc in the village of Ramgarh. To help nab him, Jai and Veeru, two ex-convicts, are hired by Thakur Baldev Singh, a retired policeman.
I feel that Gabbar Singh more of a Management Guru than a dacoit. Some of the timeless management lessons he promulgates through his Dialogues in the blockbuster movie Sholay are given below:

1. Jo Dar Gaya Samjho Mar Gaya – If you don’t have the appetite to take the risk don’t start your own business or work in a Startup, its like jungle, survival of the fittest.

2. Kitne Admi Thhey? – It’s always important to understand your competition well and change the game plan accordingly, there is no one size fits all strategy.

3. Yeh Ramgarh Waale Apni Betiyon Ko Kaunsi Chakki Ka Aata Khilate Hai Re – To be able to give a better value proposition it is important to do thorough Market research and devise penetration strategy to have a competitive edge over your rivals.

4. Yeh Haath Hamka Dede Thakur – Do a thorough SWAT Analysis to Identify threats in the market and take measures to minimize the same.

5. Holi Kab Hai, Kab Hai Holi? – Always know which all festivals are important for your TG and keep your event calendar planned to avoid last minutes rush.

6. Itna Sanatta Kyun Hai Bhai? – Out of sight, out of mind, you don’t want your customers to forget you. Always have a strategy to stay top of the Mind.

7. Bahut Yarana Lagta Hai? – Always keep an eye on what’s happening around you in office space and outside, you never know what can come handy in which situation, you should have a good sense of timing while applying the ‘carrot and stick approach’.

8. Arey O Sambha, Kitna Inaam Rakhe Hai Sarkar Hum Par? – Every now and then it is important to make sure everyone around you know your worth

9. Tera Kya Hoga Kaaliya? – Employee feedback is important. Always ask for their feedback before taking a decision on them.

10. 6 Goli, Aur Aadmi 3, Bohot Naa Insaafi Hai! – Always make your team members believe that you are on their side and want to give them a fair chance to perform and save their jobs or get promoted whatever is the case…

11. Le Ab Goli Kha – …but when it comes to performance review the line says it all, you get the idea right?