DEV Community: Made Büro

No Hype, No Shortcuts: A Free MIT Course That Prepares You to Build a Startup

Made Büro — Sun, 29 Mar 2026 15:33:11 +0000

After 12+ years of building digital products, OSS tools, I've noticed that the most useful resources rarely go viral. They're too honest for that.

This MIT course by Joe Hadzima is one of them.
Nuts and Bolts of New Ventures is free, open to everyone, and one of the most grounded resources on startups I've seen in a while. No hype, no shortcuts, no startup mythology. Just practical thinking about why most startups fail and what actually improves your odds.
At a time when so much startup advice is optimized for attention, this course feels refreshingly different.

Why this course stands out

The title of the first session says everything:

"Most Startups Fail: How to Improve Your Odds"

That's the spirit of the whole course.
It doesn't try to sell entrepreneurship as a glamorous path. It treats it as what it really is: a difficult, uncertain, deeply practical process that requires much more than enthusiasm and a good idea.

The four things that actually matter

One of the core frameworks in the course is a simple but powerful idea: a venture needs alignment across four things:

Idea – Is there a real problem worth solving?
Execution – Can you actually build and deliver it?
Timing – Is the market ready right now?
People – Do you have the right team?

A lot of startup content overemphasizes the idea and underestimates everything else. In reality, getting even two of these right is hard. Getting all four aligned is rare.
That's also why so many startups fail.

The gap that gets underestimated

One of the most honest points in the course is the gap between wanting to be a founder and doing the actual work of building a company.

The idea of building a startup is attractive. The day-to-day reality is much less romantic: customer discovery, defining the market, sales, legal basics, hiring, uncertainty, trade-offs, and constant decisions with incomplete information.

That operational gap is where many ventures break down – not because founders lack ambition, but because building something real is far more complex than it looks from the outside.

Who this course is useful for

I'd recommend it especially if you are:

Building a side project and thinking about turning it into a business
Early in your founder journey and looking for a solid mental model
Already experienced, but want a practical refresher from first principles

The course includes 11 sessions and covers topics like market definition, sales, legal structure, and fundraising.

Personal note

I'm currently building OneBit, GEO AI and Context AI CLI, both open source, both early stage. And even with years of experience, the four-element framework from this course is something I keep coming back to.

Not because it's new. Because it's a useful reality check when you're deep in execution and lose perspective on timing or people.

The best frameworks aren't the most complex ones. They're the ones you can actually apply when things get hard.

Links
YouTube: https://www.youtube.com/watch?v=5gtR7IjtcFE
MIT: https://ocw.mit.edu/courses/15-393-nuts-and-bolts-of-new-ventures-january-iap-2025/pages/session-1/

From MIT. Absolutely worth your time.

AI context management across Claude, Cursor, Kiro, Gemini and custom agents

Made Büro — Mon, 23 Mar 2026 06:43:31 +0000

If you use more than one AI coding agent, you've probably noticed that each one wants its own context file.

Claude Code reads CLAUDE.md. Cursor reads .cursorrules. GitHub Copilot reads .github/copilot-instructions.md. Kiro reads .kiro/steering/*.md. Windsurf reads .windsurf/rules/*.md. Gemini CLI and Antigravity read GEMINI.md. And then there's AGENTS.md and llms.txt.

That's nine different files describing the same thing: your project's stack, architecture, and coding conventions.

Most of them contain nearly identical content. But they go out of sync the moment someone updates one and forgets the rest. The result is that your AI agent gives inconsistent suggestions depending on which tool you're using.

One config, every agent

contextai is a CLI that generates all of these from a single TypeScript config:

import { defineContext } from 'contextai';

export default defineContext({
  project: {
    name: 'my-app',
    stack: ['TypeScript', 'React', 'Node.js'],
    architecture: 'Monorepo with shared packages',
  },
  conventions: {
    code: [
      {
        title: 'Naming',
        items: ['camelCase for variables', 'PascalCase for components'],
      },
    ],
    testing: [
      {
        title: 'Unit tests',
        items: ['Use Vitest', 'Colocate test files with source'],
        scope: 'agent-only',
      },
    ],
  },
  outputs: {
    'AGENTS.md': true,
    'CLAUDE.md': true,
    '.cursorrules': true,
    '.github/copilot-instructions.md': true,
    'llms.txt': true,
    '.kiro/steering': true,
    '.windsurf/rules': true,
    'GEMINI.md': true,
  },
});

Then:

npx contextai generate

All nine files created from one source. Change a convention, run generate again, everything stays in sync.

Supported output targets

Target	File
Claude Code	`CLAUDE.md`
Cursor	`.cursorrules`
Codex / generic agents	`AGENTS.md`
GitHub Copilot	`.github/copilot-instructions.md`
Kiro (AWS)	`.kiro/steering/*.md`
Windsurf	`.windsurf/rules/*.md`
Gemini CLI / Antigravity	`GEMINI.md`
AI search engines	`llms.txt`
Custom	any path via config

Each generator respects the target's native format. Kiro gets YAML frontmatter with inclusion: always. Windsurf gets trigger: always_on. Gemini gets clean markdown. You don't have to think about format differences.

Project scanner

contextai init inspects your project root — reads package.json, tsconfig.json, framework configs — and bootstraps a context.config.ts with detected stack and sensible defaults.

Built-in convention templates are available for Next.js, NestJS, Express, Remix, and SvelteKit:

export default defineContext({
  templates: ['nextjs'],
  // ...
});

Convention scoping

Sometimes you want technical depth for AI agents that doesn't belong in human-facing docs:

conventions: {
  security: [
    {
      title: 'Auth patterns',
      items: ['Use JWT tokens', 'Rotate secrets quarterly'],
      scope: 'agent-only',
    },
  ],
}

agent-only sections appear in all generated output files. human-only sections are excluded from AI context entirely.

Custom generators

New AI tools appear regularly. Custom generators let you target anything without waiting for a contextai update:

outputs: {
  'CLAUDE.md': true,
  custom: [
    {
      path: 'docs/ai-context.md',
      generator: (config) => `# ${config.project.name}\n${config.project.architecture}`,
    },
  ],
}

Keeping things in sync

contextai validate — checks that output files exist and aren't stale
contextai diff — shows what would change without writing anything
contextai generate --dry-run — preview mode
contextai watch — regenerates automatically when config changes
Git hook — contextai init can install a pre-commit hook that runs generate before every commit

JSON output for CI

contextai generate --format json

Outputs the full intermediate representation to stdout instead of writing files. Useful for CI pipelines, piping into other tools, or debugging.

Type-safe environment validation

Made Büro — Sat, 21 Mar 2026 15:13:51 +0000

Environment variables are one of those things that look simple until they start breaking production.

A missing DATABASE_URL, an invalid PORT, a typo in NODE_ENV, or a leaked secret in logs — all of these come from the same place: process.env is just untrusted input.

That's why I made EnvZen: an Open Source toolkit for validating environment variables in TypeScript / Node.js. It validates process.env against a schema at startup, returns typed config, redacts sensitive values, and includes a CLI for scaffolding, checking, and syncing .env files.

The problem with process.env

In most Node.js apps, environment variables are used everywhere but validated nowhere.

That usually leads to a few common problems:

Values are missing, but you only find out after deploy
Everything is a string, so type coercion gets repeated across the codebase
Config rules live in people's heads instead of code
Secrets accidentally end up in logs or JSON output

The core idea behind EnvZen is simple: treat env variables like runtime input and validate them at boot time. EnvZen throws a structured EnvValidationError when required values are missing, invalid, or the wrong type. It also infers TypeScript types directly from the schema.

Quick start

Install the core package:

npm install envzen-core

Then define your schema:

// env.ts
import { createEnv } from 'envzen-core'

export const env = createEnv({
  NODE_ENV: {
    type: 'enum',
    values: ['development', 'production', 'test'],
    default: 'development',
  },
  PORT: {
    type: 'port',
    default: 3000,
  },
  DATABASE_URL: {
    type: 'url',
    required: true,
    sensitive: true,
  },
  API_KEY: {
    type: 'string',
    required: true,
    sensitive: true,
  },
})

And use it in your app:

// index.ts
import 'dotenv/config'
import { env } from './env.js'

console.log(env.PORT)           // number
console.log(env.NODE_ENV)       // 'development' | 'production' | 'test'
console.log(JSON.stringify(env)) // sensitive fields are redacted

EnvZen does not load .env files for you — if you use dotenv, call it before createEnv().

What EnvZen gives you

The core package is built around a schema-driven API.

Supported field types: string, number, boolean, port, url, email, enum.

You can also mark fields as:

required — must be present, no fallback
default — fallback value when variable is absent
description — used in .env.example output
sensitive — redacted in logs, errors, and JSON.stringify()
validate — additional Zod-based validation on top of the base type

That means your environment config becomes a real contract instead of a pile of implicit assumptions.

Safer logging by default

One thing I cared about from the start was avoiding secret leaks.

If a field is marked as sensitive, EnvZen automatically redacts it in toJSON() and JSON.stringify(). Sensitive values are also redacted from validation error messages.

That makes it much safer to inspect config or print error output without accidentally exposing credentials.

CLI for real workflows

Besides the runtime library, there's also envzen-cli:

npm install -g envzen-cli

Available commands:

envzen init                              # scaffold env.ts config
envzen sync --schema ./env.ts            # generate .env.example from schema
envzen check --schema ./env.ts --env .env # diff .env against schema

init scaffolds an env.ts config file. sync generates .env.example from your schema — always up to date. check diffs your .env against the schema and reports missing, extra, or invalid variables.

CI mode is also supported:

envzen init --ci
envzen check --ci

Framework adapters

EnvZen works beyond plain Node.js apps with adapters for several common setups:

// Express / Fastify
import { envGuardMiddleware } from 'envzen-express'
app.use(envGuardMiddleware(schema))

// Vite
import { envGuardPlugin } from 'envzen-vite'
export default { plugins: [envGuardPlugin(schema)] }

// Next.js
import { withEnvGuard } from 'envzen-next'
export default withEnvGuard(nextConfig, schema)

// NestJS
import { EnvGuardModule } from 'envzen-nestjs'
@Module({ imports: [EnvGuardModule.forRoot(schema)] })

Each adapter validates at the framework's startup lifecycle. Invalid env = the app doesn't start.

Error handling

When validation fails, EnvZen throws EnvValidationError with both a formatted message and a structured failures array:

import { createEnv, EnvValidationError } from 'envzen-core'

try {
  const env = createEnv(schema)
} catch (err) {
  if (err instanceof EnvValidationError) {
    console.error(err.message)   // human-readable summary
    console.error(err.failures)  // ValidationFailure[]
  }
}

Why I made this

There are already good libraries in this space, but I wanted something with a few specific properties:

Schema-first API with full TypeScript inference
Sensitive values redacted by default, not opt-in
CLI that keeps .env.example in sync automatically
Lightweight adapters for Express, NestJS, Next.js, Vite

The goal was not just "validate env vars" but to make environment configuration feel like part of the application contract.

Try it out

GitHub: github.com/madeburo/envzen
npm: envzen-core · envzen-cli
License: MIT

Feedback, issues, and contributions are welcome.

NestJS Module for AI Search Optimization

Made Büro — Tue, 17 Mar 2026 14:05:46 +0000

Over the past few weeks I’ve been building GEO AI an Open Source ecosystem around AI Search Optimization.

The core idea is simple: if AI systems are going to read and reason about websites, then websites need a clearer way to expose structured content, crawler rules, and machine-readable signals.

Why a separate package for NestJS?

NestJS developers expect framework-native primitives: modules, DI, middleware, guards, interceptors, decorators. Asking them to manually call createGeoAI() and wire everything by hand would feel wrong.

So instead of a generic adapter, I built geo-ai-nest as a thin NestJS layer on top of geo-ai-core. All the GEO logic stays in the core package. The Nest package only adapts it to how Nest apps are structured.

Quick start
npm install geo-ai-nest geo-ai-core

import { Module } from '@nestjs/common';
import { GeoAIModule } from 'geo-ai-nest';

@Module({
  imports: [
    GeoAIModule.forRoot({
      siteName: 'My App',
      siteUrl: 'https://myapp.com',
      provider: {
        pages: [
          { title: 'About', url: '/about', description: 'About us' },
          { title: 'Pricing', url: '/pricing', description: 'Our plans' },
        ],
      },
      crawlers: 'all',
    }),
  ],
})
export class AppModule {}

That's it. Your app now serves:

GET /llms.txt — compact content index
GET /llms-full.txt — full content with descriptions
GET /.well-known/llms.txt — standard discovery path
GET /robots-ai.txt — per-bot crawler rules
No extra controllers needed.

Async configuration

Real apps usually load config from a database or config service. forRootAsync handles that:

GeoAIModule.forRootAsync({
  imports: [ConfigModule],
  useFactory: (config: ConfigService) => ({
    siteName: config.get('SITE_NAME'),
    siteUrl: config.get('SITE_URL'),
    provider: { pages: [] }, // your ContentProvider here
    crawlers: 'all',
    injectLinkHeader: true,
    cacheMaxAge: 7200,
  }),
  inject: [ConfigService],
}),

Detecting AI bots in your routes

The @IsAIBot() parameter decorator tells you which AI crawler is hitting your endpoint — or null if it's a regular user:

import { Controller, Get } from '@nestjs/common';
import { IsAIBot } from 'geo-ai-nest';

@Controller('api')
export class CatalogController {
  @Get('products')
  getProducts(@IsAIBot() bot: string | null) {
    if (bot) {
      console.log(`AI crawler detected: ${bot}`);
      // return enriched response for AI consumption
    }
    return this.productService.findAll();
  }
}

Protecting routes from non-AI traffic

GeoAIGuard restricts a route to verified AI bot requests only:

import { UseGuards } from '@nestjs/common';
import { GeoAIGuard } from 'geo-ai-nest';

@UseGuards(GeoAIGuard)
@Get('ai-only')
getAiContent() {
  return { data: 'Only AI crawlers can see this' };
}

Why middleware for llms.txt instead of a controller?
This was a deliberate choice. Middleware runs before the routing layer, which means:

It intercepts requests before guards, interceptors, or pipes run
It works regardless of how the app's routing is structured
It avoids conflicts with catch-all routes or global prefixes

The robots-ai.txt endpoint uses a controller because it's a standard REST resource that benefits from Nest's decorator pipeline.

Where it fits in GEO AI

At this point, the GEO AI ecosystem looks something like this:

geo-ai-core — universal engine
geo-ai-next — Next.js integration
geo-ai-nest — NestJS integration
geo-ai-cli — CLI for any Node.js project

The core package remains the center of gravity, and the framework packages are really adapters around it. The main GEO AI README now describes geo-ai-nest as the NestJS wrapper alongside the Next.js and CLI packages.

I like this structure because it keeps the real logic in one place while still making adoption feel native inside each framework.

What I wanted from this release
More than anything, I wanted NestJS developers to be able to say:

“Install one package, register one module, and get the GEO surface area in a way that feels like Nest.”

That includes:

dynamic module registration
automatic llms routes
a built-in robots endpoint
DI-friendly service access
optional route protection for AI bots
optional response header injection
decorators that fit how Nest apps are already written

That was the bar.

Links
Website
Docs
GitHub
npm

CLI for AI Search Optimization in Node.js projects

Made Büro — Thu, 12 Mar 2026 16:57:50 +0000

If you've been following the AI search space, you've probably heard about llms.txt – a simple Markdown file that tells AI crawlers (ChatGPT, Claude, Perplexity, Gemini, DeepSeek etc.) what your site is about and what content they're allowed to use. Think of it as robots.txt, but designed for the LLM era.

In this post I'll walk through how I built a CLI tool – geo-ai-cli — that generates and validates these files for any Node.js project, and share some of the interesting design decisions along the way.

What is llms.txt?

The llms.txt proposal defines a standard for exposing structured site content to AI systems. Two files:

llms.txt – a compact summary: site name, description, and a list of key pages with titles and URLs
llms-full.txt – the same, but with full content for each page
A minimal llms.txt looks like this:

# My SaaS Product

> A brief description for AI crawlers.

## Pages

- [Home](https://example.com/): Welcome page
- [Pricing](https://example.com/pricing): Plans and pricing

## Blog

- [Getting Started](https://example.com/blog/start): First steps guide

AI search engines like Perplexity, Claude and ChatGPT browse these files to understand your site's content and include it in answers. It's essentially GEO – Generative Engine Optimization.

The CLI

npm install --save-dev geo-ai-cli

Four commands cover the full workflow:

npx geo-ai init      # scaffold a config file
npx geo-ai generate  # generate llms.txt + llms-full.txt
npx geo-ai validate  # check output files are valid
npx geo-ai inspect   # preview config and crawler rules

init
Scaffolds a geo-ai.config.ts in the current directory. If a config already exists, it exits without overwriting – safe to run multiple times.

// geo-ai.config.ts
import type { GeoAIConfig } from 'geo-ai-core';

export default {
  siteName: 'My Site',
  siteUrl: 'https://example.com',
  siteDescription: 'A brief description for AI crawlers.',
  crawlers: 'all',
  provider: {
    Pages: [
      { title: 'Home', url: 'https://example.com/', description: 'Welcome page' },
    ],
    Blog: [
      { title: 'Getting Started', url: 'https://example.com/blog/start', description: 'First steps' },
    ],
  },
} satisfies GeoAIConfig;

The provider field is a plain object where each key becomes a section in llms.txt. You can also pass a ContentProvider instance if you want to pull data from a CMS or API dynamically.

generate
Loads your config, calls createGeoAI(config) from geo-ai-core, and writes both files to ./public (or wherever you point --out):

npx geo-ai generate --out ./dist/public

Config discovery follows a priority order: geo-ai.config.ts → geo-ai.config.js → geo-ai.config.json. TypeScript configs are loaded via dynamic import(), so you get full type safety without a separate compilation step.

validate
Checks that the generated files are present and structurally valid. Works on local files or a live URL:

# local
npx geo-ai validate --path ./public

# remote
npx geo-ai validate --url https://example.com

Validation rules are intentionally simple:

file missing: not_found
content < 50 chars: warn
doesn't start with #: fail
starts with #: pass

Exit code 1 on any fail or not_found, so it integrates cleanly into CI:

# .github/workflows/deploy.yml
- run: npx geo-ai generate
- run: npx geo-ai validate

inspect
Prints a human-readable summary of your config: site info, which AI bots are allowed/disallowed, and how many items are in each section. Useful for debugging before you generate.

npx geo-ai inspect

# Site: My Site
# URL:  https://example.com
# Out:  ./public
# Crawlers:
#   GPTBot: allow
#   ClaudeBot: allow
#   PerplexityBot: allow
#   ...
# Sections:
#   Pages: 3 item(s)
#   Blog: 12 item(s)

You can also point it at a live URL to fetch and display the remote files:

npx geo-ai inspect --url https://example.com

Adding it to your build pipeline

The most useful place for geo-ai generate is right before your deployment step:

// package.json
{
  "scripts": {
    "build": "next build && geo-ai generate",
    "postbuild": "geo-ai validate"
  }
}

Or in CI:

- name: Build
  run: npm run build

- name: Generate llms.txt
  run: npx geo-ai generate

- name: Validate
  run: npx geo-ai validate --url ${{ env.SITE_URL }}

Controlling which AI bots can crawl

By default, crawlers: 'all' allows all 16+ known AI bots. You can get granular:

export default {
  siteName: 'My Site',
  siteUrl: 'https://example.com',
  crawlers: {
    GPTBot: 'allow',
    ClaudeBot: 'allow',
    PerplexityBot: 'allow',
    'Google-Extended': 'disallow', // opt out of Gemini training
    Bytespider: 'disallow',        // TikTok crawler
  },
  provider: { /* ... */ },
} satisfies GeoAIConfig;

The geo-ai-core engine uses this to generate a corresponding robots.txt block and per-bot allow/disallow rules in the llms files.

What's next

The CLI is part of a larger ecosystem:

geo-ai-core — the zero-dependency engine (llms.txt generation, bot rules, crawl tracking, SEO signals, AI description generation via Claude/OpenAI)
geo-ai-next — a thin Next.js wrapper with middleware and App Router handler
WordPress and Shopify integrations

The geo-ai-core/ai entry point lets you bulk-generate AI descriptions for your content using Claude or OpenAI, with a built-in rate limiter and batching – but that's a topic for another post.

If you're building a public-facing Node.js project, adding llms.txt takes about 5 minutes and meaningfully improves how AI search engines understand your content. Give it a try:

npx geo-ai init

Links
Website: https://www.geoai.run
CLI page: https://www.geoai.run/cli
CLI docs: https://www.geoai.run/docs/integrations/cli
GitHub: https://github.com/madeburo/GEO-AI

How to optimize Next.js project for AI search engines

Made Büro — Fri, 06 Mar 2026 08:47:10 +0000

AI search engines like ChatGPT, Perplexity, Claude, and Gemini are becoming a major discovery channel. When someone asks them "recommend me a good product or service", they pull data from structured content, dedicated crawlers, and formats like llms.txt to generate answers.

Optimizing for this is called Generative Engine Optimization (GEO) – and it requires a different approach than traditional SEO.

In this guide, I'll show you how to optimize your Node.js or Next.js app for 16 AI search engines using an open-source TypeScript engine called GEO AI Core.

For any Node.js project:
npm install geo-ai-core

For Next.js specifically:
npm install geo-ai-next

Define your content

The simplest way is to pass your content directly:

import { createGeoAI } from 'geo-ai-core';

const geo = createGeoAI({
  siteName: 'My Store',
  siteUrl: 'https://example.com',
  provider: {
    Products: [
      { title: 'Widget', url: '/products/widget', description: 'A great widget' },
    ],
    Blog: [
      { title: 'Hello World', url: '/blog/hello', description: 'First post' },
    ],
  },
});

For dynamic data (CMS, database, API), implement the ContentProvider interface:

import { createGeoAI, type ContentProvider } from 'geo-ai-core';

class StrapiProvider implements ContentProvider {
  async getSections(options?: { locale?: string }) {
    return [
      { name: 'Products', type: 'product', resources: await fetchProducts() },
      { name: 'Blog', type: 'page', resources: await fetchPosts() },
    ];
  }
}

const geo = createGeoAI({
  siteName: 'My Store',
  siteUrl: 'https://example.com',
  provider: new StrapiProvider(),
  crawlTracking: true,
});

Generate llms.txt

llms.txt is a structured file that helps AI crawlers understand your site – like a sitemap, but designed for LLMs.

// Standard version — resource links with descriptions
const llmsTxt = await geo.generateLlms(false);

// Full version — includes content, pricing, availability, variants
const llmsFullTxt = await geo.generateLlms(true);

Add SEO signals for AI

// Meta tags for AI content discovery
const metaTags = geo.generateMetaTags();

// HTTP Link header
const linkHeader = geo.generateLinkHeader();

// JSON-LD (WebSite, Product, Article)
const jsonLd = geo.generateJsonLd();

// Robots.txt block with AI bot rules
const robotsTxt = geo.generateRobotsTxt();

Next.js: Wire it up with middleware

If you're using Next.js, geo-ai-next makes this even simpler – just add the middleware:

// middleware.ts
import { geoAIMiddleware } from 'geo-ai-next';

export default geoAIMiddleware({
  siteName: 'My Store',
  siteUrl: 'https://example.com',
  provider: new MyProvider(),
  cache: '24h',
  injectLinkHeader: true,
});

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
};

This automatically serves /llms.txt and /llms-full.txt and injects Link headers into all responses.

Or use an App Router route handler:

// app/llms/route.ts
import { createLlmsHandler } from 'geo-ai-next';

export const { GET } = createLlmsHandler({
  siteName: 'My Store',
  siteUrl: 'https://example.com',
  provider: new MyProvider(),
});

That's it. Your Next.js app is now optimized for AI search engines.

AI-powered descriptions

GEO AI Core can also generate AI-optimized descriptions for your content via Claude or OpenAI:

import { AiGenerator } from 'geo-ai-core/ai';

const ai = new AiGenerator({
  provider: 'anthropic',
  apiKey: 'sk-...',
  model: 'claude-sonnet-4-20250514',
});

const description = await ai.generate({
  title: 'Premium Widget',
  content: 'A high-quality widget...',
  type: 'product',
  price: '$29.99',
});

Bulk generation with progress tracking:

const results = await ai.bulkGenerate(items, {
  batchSize: 5,
  maxItems: 50,
  onProgress: ({ completed, total }) => console.log(`${completed}/${total}`),
});

What AI crawlers are supported?

GPTBot, OAI-SearchBot, ClaudeBot, claude-web, Google-Extended, PerplexityBot, DeepSeekBot, GrokBot, meta-externalagent, PanguBot, Bytespider, Baiduspider, Amazonbot, Applebot.

Technical highlights

Zero runtime dependencies
TypeScript with full type declarations
Dual ESM/CJS build
114 tests (unit + property-based via fast-check)
GDPR-compliant crawl tracking with SHA-256 IP anonymization
Pluggable caching and storage
Node.js 20+

Links
GEO AI: https://www.geoai.run/
GitHub: github.com/madeburo/GEO-AI
npm: geo-ai-core / geo-ai-next

All big things grow from small wedges in the market.

GEO for Shopify: How to Get Your Products Into ChatGPT, Claude & Perplexity Results

Made Büro — Thu, 05 Mar 2026 07:05:44 +0000

When someone asks ChatGPT "best running shoes for flat feet" or Perplexity "recommend a minimalist wallet" AI engines don't just crawl your sitemap. They need structured, machine-readable content that fits inside a context window. Your product data is trapped in Liquid templates, JavaScript, and navigation – LLMs waste tokens parsing it.

This is Generative Engine Optimization (GEO) – making your store visible to AI search engines.

I built an open-source Shopify app to solve this – GEO AI Shopify.

What GEO AI Shopify Does

GEO AI Shopify is a free, open-source embedded Shopify app that makes your store AI-readable with zero configuration.

The app generates llms.txt and llms-full.txt – structured Markdown files served via Shopify App Proxy at /apps/llms/. Think of llms.txt as robots.txt for AI: instead of telling crawlers what not to index, it tells AI engines what to read and how to understand it.
Content is cached in the database with configurable TTL and regenerated automatically when you update products, pages, or collections — all via webhooks, no manual intervention.

AI Crawlers Supported

ChatGPT, Copilot, Claude, Claude Web, Gemini, Perplexity, DeepSeek, Grok, LLaMA, Qwen, YandexGPT, GigaChat, Douyin, Ernie, Alexa and Siri.

Shopify-Native Architecture

This isn't a generic llms.txt generator bolted onto Shopify. It's built as a proper embedded app with the full Shopify stack:

Remix v2 + Vite — modern SSR framework
Shopify Polaris — native admin UI
Prisma ORM — type-safe database access
App Bridge — seamless admin integration
GraphQL Admin API — cursor-based pagination, exponential backoff, proactive throttling
Webhook-driven — cache invalidates automatically on product/page/collection changes
App Proxy — llms.txt served at /apps/llms/ with HMAC-SHA256 signature verification
Theme Extension — injects and JSON-LD Schema.org directly into storefront

Metafields Integration
AI metadata lives where it should — as Shopify Metafields (namespace: geo_ai):

AI Description — concise summary for LLMs (max 200 chars)
AI Keywords — topics and context hints
Exclude from AI — opt specific content out of llms.txt
Auto-registration of metafield definitions on first use

AI-Powered Descriptions
Generate AI summaries via Claude or OpenAI APIs:

One-click generation per product/page
Bulk generation for up to 50 resources (batched by 5, rate limited)
Customizable prompt templates with {title}, {content}, {type}, {price}, {category} placeholders
AES-256-GCM encrypted API key storage

Why This Matters Now

Shopify recently published their own GEO Playbook acknowledging that AI discovery is the next frontier for commerce. OpenAI's Agentic Commerce Protocol — launched with Shopify, Etsy, and Walmart — lets AI agents complete purchases directly. McKinsey projects agentic commerce will reach $3-5 trillion by 2030.

If your store isn't optimized for AI search today, you're already falling behind.

Why Open Source

Most Shopify GEO solutions are either paid apps or closed-source SaaS. GEO AI Shopify is GPL v2, fully open, and free. Merchants everywhere — especially those in emerging markets — deserve AI visibility without a monthly subscription.

Try It
GEO AI: https://www.geoai.run/
GitHub: https://github.com/madeburo/GEO-AI-Shopify
Install it, check your /apps/llms/ endpoint, and see what AI engines can (or can't) find about your products.

Feedback, issues, and PRs welcome.

Make Your WooCommerce and WordPress site visible to ChatGPT, Claude, Perplexity, Grok and more

Made Büro — Wed, 04 Mar 2026 09:43:03 +0000

ChatGPT handles over 1 billion queries daily. Perplexity processes 780+ million searches per month. Google's AI Overviews now appear on 30%+ of searches.

And your WooCommerce store? Invisible to all of them.

Traditional SEO optimizes for Google's link-based index. But when someone asks ChatGPT "best wireless headphones under $100" or Claude "recommend a CRM for small teams" — those AI engines don't crawl your sitemap. They look for structured, machine-readable content that fits inside a context window.

This is Generative Engine Optimization (GEO) — making your content visible to AI search engines, not just traditional ones.

I built an open-source WordPress plugin to solve this for WooCommerce stores.

The Problem

Your products have titles, descriptions, prices, reviews — all the data AI engines need. But it's buried in HTML, JavaScript, navigation menus, and sidebar widgets. LLMs waste their token budget parsing

soup instead of understanding your catalog.

Meanwhile, robots.txt was designed for Googlebot in 2004. It tells crawlers what not to index. There's nothing that tells AI engines what to index and how to read it.

That's what llms.txt does — a structured Markdown file at your site root, specifically designed for LLMs. Think of it as robots.txt for the AI era, but instead of blocking, it guides.

What GEO AI Woo Does

GEO AI Woo is a free, open-source WordPress plugin that makes your site AI-readable with zero configuration.

Automatic llms.txt Generation
The plugin generates /llms.txt and /llms-full.txt as static files at your WordPress root. Products, pages, and posts — structured and ready for 13 AI crawlers: ChatGPT, Claude, Gemini, Perplexity, DeepSeek, Grok, LLaMA, Qwen, ERNIE etc.

WooCommerce-First

This isn't a generic llms.txt generator. It understands WooCommerce:

Products automatically included with price, stock status, ratings, and attributes
Variable products show price ranges and available variations
Sale prices display both regular and discounted values
Enhanced Schema.org markup (JSON-LD) for Product and Article types
Dedicated GEO AI tab in the WooCommerce product data panel

AI-Powered Descriptions

Don't want to write AI summaries manually? The plugin generates them via Claude or OpenAI APIs:

One-click generation per post/product
Bulk generation (up to 50 at a time)
Customizable prompt templates with {title}, {content}, {type} placeholders
Encrypted API key storage

Quick Start

After activation, the plugin works immediately with sensible defaults. All public posts, pages, and products are included in llms.txt. All supported AI crawlers are allowed.

Go to Settings and GEO AI Woo to customize post types, bot rules, cache frequency, and WooCommerce-specific settings.

GEO AI Woo is GPL v2, fully open, and free.

What's Next

Shopify version
GEO Ai Core
More crawlers as new AI search engines emerge

Try It

GEO AI: https://www.geoai.run/

GitHub: https://github.com/madeburo/GEO-AI-Woo

Feedback, issues, and PRs welcome.