DEV Community: Made Büro

Brewwery a native macOS GUI for Homebrew

Made Büro — Wed, 16 Sep 2026 15:20:37 +0000

Homebrew is usually one of the first tools I install on a new Mac. Its command-line interface is fast, reliable, and familiar. But over time, a Homebrew installation becomes more than a short list of packages.

There are formulae, casks, taps, background services, outdated dependencies, cleanup opportunities, diagnostics, and Brewfiles.

The commands exist, but answering simple questions can still require several of them:

What is installed?

Which services are running?

What needs an update?

What depends on this package?

How much space would cleanup recover?

I wanted to see the state of my entire Homebrew setup without scrolling through terminal output or remembering a different command for every task.

So I built Brewwery.

Homebrew, made visual with Brewwery

Brewwery is an open-source macOS app for managing Homebrew through one native interface.

It covers the workflows I use regularly:

view installed formulae and casks;
discover and search for new packages;
save favorites;
install, uninstall, and upgrade packages;
inspect dependencies and installed dependents;
filter Homebrew leaves;
add and remove taps;
start, stop, and restart services;
preview and run cleanup;
run brew doctor;
export a reproducible Brewfile;
and review local operation history.

Large package lists are virtualized and keyboard-friendly, so they remain responsive even when a Mac has accumulated a substantial Homebrew setup.

The goal is not to replace Homebrew. Brewwery uses the existing Homebrew installation on your Mac and gives its state and operations a clearer interface.

Version 1.0 is completely native

The first release-candidate versions of Brewwery used Electron, Node, and a Rust backend.

Brewwery 1.0 is a complete rewrite in:

Swift 6;
SwiftUI;
AppKit;
and Foundation.

There is no Electron, Node, Rust runtime, WebView, or JavaScript bridge in the new app.

The rewrite keeps the same product rather than reducing it to a smaller “native edition”: the same screens, Homebrew operations, validation rules, visual language, and safety model are still there.

The result starts faster, uses less memory, and behaves more like the macOS utility it was always intended to be.

Brewwery 1.0 also supports automatic application updates through Sparkle. These are intentionally separate from Homebrew package updates—the app updating itself should never be confused with changing the software managed by Homebrew.

A GUI should not become an arbitrary command runner

The most important part of a Homebrew GUI is not the package grid or the install button.

It is the boundary between that button and the system.

Brewwery’s interface cannot construct an arbitrary command line. Every supported operation is represented by a closed HomebrewCommand type.

The execution path looks like this:

SwiftUI view
  → feature model
    → HomebrewClient
      → validated HomebrewCommand
        → HomebrewRunner
          → ChildProcess
            → brew

Dynamic values such as package, cask, service, and tap names are validated before an argument array can be created.

Commands are launched directly with posix_spawn. No shell is involved, so user-controlled values are never interpolated into a shell command.

Brewwery also follows a few strict rules:

it never runs arbitrary commands;
it never uses sudo;
mutating operations require explicit confirmation;
cleanup requires a preview before confirmation;
only one mutating operation can run at a time;
and operations have fixed safety timeouts.

When an active operation is cancelled, Brewwery terminates its process group—not only the main brew process. This also stops helper processes such as git or curl that Homebrew may have started.

Read-only checks stay read-only

Background activity deserves the same care as visible buttons.

For example, Brewwery can check which packages are outdated and show the count in the Dock. That background check runs only:

brew outdated --json=v2

It does not silently run brew update, install anything, upgrade anything, or clean the system.

Actions that may change the Homebrew installation always remain visible and confirmation-gated.

This distinction matters because a friendly interface should make system operations easier to understand—not make them easier to trigger accidentally.

Local-first, without an account

Brewwery does not require:

an account;
authentication;
cloud sync;
a subscription;
or a telemetry opt-in screen.

There is no telemetry.

Favorites, settings, and operation history stay on the Mac. Brewwery itself does not send data to an external service. Homebrew may still access the network when it downloads package metadata or software, but Brewwery does not add its own cloud layer on top.

The app is also open source under the MIT License, so its command handling and security boundaries can be inspected directly.

Testing Homebrew without changing the developer’s Mac

Testing a package manager interface has an obvious risk: a careless test suite can modify the machine running it.

Brewwery separates its tests into several layers.

Core and application tests use a scripted brew double. They cover parsers, validation, command execution, cancellation, operation history, navigation, accessibility, and rendering without touching the real Homebrew installation.

Visual tests can render every screen in light and dark mode for review.

There is also an opt-in live test suite for real Homebrew integration. It is never enabled by default because it deliberately installs and removes test packages, controls services, and manages a test tap.

This separation lets the normal test suite remain fast and safe while still providing a deliberate path for end-to-end verification.

The terminal is still there when you need it

A visual interface should not hide useful information.

Brewwery shows live progress for installs, upgrades, service actions, and cleanup. Successful operations can close automatically, while failures and cancellations stay visible so their output can be inspected.

For quick daily work, the interface provides clear actions and status. When something goes wrong, the underlying Homebrew output is still available.

That balance is important: convenience when everything works, detail when it does not.

Try Brewwery

Brewwery supports Apple Silicon and Intel Macs running macOS 14 Sonoma or later.

You can:

If you use Homebrew regularly, I would love to hear which command or workflow you would most like to manage visually.

Brewwery. Homebrew, made visual.

UsageNow Tracks OpenAI Codex, Claude Code, Gemini and Antigravity Usage from Your Mac Menu Bar

Made Büro — Wed, 16 Sep 2026 15:13:34 +0000

I rarely use just one AI coding tool anymore. Codex may be working on one task, Claude Code on another, Gemini CLI is useful for a different workflow, and Antigravity has its own strengths.

The problem is that every tool has a different way of reporting usage:

different limit windows;
different reset times;
different definitions of “usage”;
and sometimes no accessible quota information at all.

I kept asking the same questions:

How much usage do I have left?

When does it reset?

Which model have I been using today?

Opening several apps and dashboards just to answer those questions felt unnecessary. I wanted the answer to live where I could see it immediately: in the macOS menu bar.

So I built UsageNow.

One place for AI coding usage

UsageNow is a native macOS app that brings usage information from multiple AI coding tools into one compact view.

Today it supports:

Codex
Claude Code
Gemini CLI
Antigravity

Click the menu bar icon and you can see the available limit windows, how much is left, when they reset, and today’s local token and request activity by model.

There are also small and medium desktop widgets for checking usage without opening the app.

The providers are not actually the same

One of the more interesting parts of building UsageNow was discovering how differently each tool exposes its data.

Codex

Codex limits, reset times, and account plan come from the official Codex app-server running locally. Token and request activity is calculated from session files already stored on the Mac.

UsageNow never needs to read or copy Codex credentials.

Claude Code

Claude Code stores enough local session data to calculate token activity, requests, models used, and account information.

Subscription limits are more complicated. UsageNow can fetch them through an experimental, opt-in integration using the existing Claude Code sign-in. The access token is kept in memory and sent only to Anthropic.

If this option is disabled—or the limits cannot be fetched—local activity still works.

Gemini CLI

Gemini CLI records local session activity, so UsageNow can show tokens, requests, and models used today.

It does not expose usage limits locally. Instead of estimating them or displaying a meaningless zero, UsageNow simply says that limits are unavailable.

Antigravity

While the Antigravity app is running, UsageNow asks its local language server for the same quota summary shown in Antigravity’s own usage panel.

This communication stays on 127.0.0.1. No Google credentials are read or transmitted by UsageNow.

Missing data should look missing

A surprisingly important product decision was to resist the temptation to make every provider card look complete.

If a provider returns only a weekly limit, UsageNow shows only a weekly limit.

If a quota cannot currently be refreshed, the last known value can remain visible—but it is clearly marked as stale.

If a tool does not expose limits, UsageNow says so.

And token activity is presented as local activity, not as a billing statement. Cached tokens and provider-specific accounting can make those two numbers different.

A polished but invented percentage would look nicer. It would also be wrong.

For a usage monitor, trust is more important than visual symmetry.

Local-first by design

I did not want another cloud dashboard with another account, database, or proxy sitting between developers and their AI tools.

UsageNow has no account system and no UsageNow server receiving your usage data.

It does not collect prompts, responses, source code, project names, or conversation content. For local activity, it extracts only the small set of fields it needs: timestamps, identifiers, model names, and token counts.

Providers can also be disabled individually. When a provider is disabled, UsageNow does not refresh it or read its files.

The desktop widget follows the same principle. It cannot access provider files, credentials, or the network. The main app publishes a sanitized snapshot containing only the values needed for display, and the widget renders that snapshot.

The full privacy model is documented in the UsageNow privacy documentation.

Normalizing the result, not the providers

UsageNow is built with SwiftUI and MenuBarExtra.

Internally, every integration is different, but each provider produces a normalized snapshot for the interface:

Codex app-server ─────┐
Claude session files ─┤
Gemini recordings ────┼─> ProviderSnapshot ─> Menu bar
Antigravity localhost ┘                    └─> Widget

A snapshot can contain:

zero or more usage windows;
an optional plan;
local token and request activity;
activity grouped by model;
freshness information;
and a provider-specific unavailable reason.

The UI does not assume that every provider has the same capabilities.

Providers refresh concurrently, and a failed refresh does not automatically erase the last good result. This matters for tools whose sessions expire or whose local services are only available while the tool is running.

The widget is a separate target and receives only explicitly copied display fields. Provider and credential-reading code is not compiled into it.

The project’s architecture and implementation are available in the open-source repository.

What shipped in version 0.3.0

The latest release adds Gemini CLI and Antigravity alongside Codex and Claude Code.

It also adds:

activity grouped by model;
provider reordering;
improved support for team plans;
smarter widget layouts;
clearer stale-data states;
and more reliable handling of renewed Claude Code sessions.

Cursor, GitHub Copilot, DeepSeek, and Qwen are on the roadmap—but they will only be added when there is a reliable and privacy-respecting way to obtain useful data.

Try UsageNow

UsageNow is free and open source under the MIT License. It runs on Apple silicon and Intel Macs with macOS 15 or later.

The downloadable app is signed and notarized by Apple.

You can:

If you use multiple AI coding tools, I would love to hear which provider you want to see next—and what usage information is most useful in your daily workflow.

See what’s left. Keep building.

Githubster free tool to track your GitHub followers and unfollowers

Made Büro — Thu, 21 May 2026 11:47:42 +0000

Ever looked at your GitHub following list and wondered do these people even follow me back?

I built Githubster to answer that question. It's a simple, free, open-source web app that shows you:

Who doesn't follow you back — people you follow who ignore you
Who you don't follow back — your fans you might have missed
Full following & followers lists — with search and filtering

Why I built it

I was cleaning up my GitHub following list manually. Clicking profiles one by one. After 10 minutes I thought — there has to be a better way. There were some tools out there, but most were outdated, required auth.

So I made my own.

How it works

Enter GitHub username and get the full picture. That's it.

No login required. No OAuth. No tokens (unless you want higher rate limits). Everything runs in your browser — zero data is sent to any server.

Try it
www.githubster.com

Source code
Github

MIT licensed. PRs welcome.

OpenModels: Explore LLM Models and Inference Providers

Made Büro — Mon, 11 May 2026 15:50:05 +0000

The number of LLM providers keeps growing and so does the confusion around pricing, availability and compatibility. OpenModels is an open-source project that brings structure to this landscape: a single registry where models, providers, and their relationships are documented, validated, and queryable.

Why This Matters

The AI inference ecosystem is fragmented in ways that cost teams real time and money:

The same model can cost 10x more depending on which provider you use
Latency between providers varies radically even for identical models
Uptime is unknown until you experience an outage yourself
Pricing pages change without notice, and there's no structured way to track it
Choosing a provider still means opening 15 tabs and building a spreadsheet

The AI ecosystem already has excellent tooling for training and inference. What is still missing is standardized infrastructure visibility across providers.

OpenModels focuses on that operational layer.

What is OpenModels

OpenModels is an open infrastructure project for discovering, validating, and comparing LLM models and inference providers.

The project combines:

an open registry of model and provider metadata
structured JSON schemas with automated validation
provider normalization (pricing, rate limits, regions)
real-time telemetry collection (health, latency, uptime)
a searchable web interface and REST API
operational intelligence for choosing the right provider

The goal is simple: make the modern AI inference ecosystem observable and comparable.

Current State

The registry currently tracks:

62 models — from OpenAI, Anthropic, Google, Meta, DeepSeek, Mistral, xAI and others
30 providers — including Together AI, Groq, DeepInfra, Cerebras, Fireworks, SambaNova and more
90+ provider-model mappings — each with pricing, rate limits, and region data

The public registry is community-maintained through YAML definitions on GitHub:
github.com/openmodelsrun/openmodels

Architecture

The project is intentionally split into two layers.

1. Open Registry

The public repository contains normalized ecosystem data:

openmodels/
├── models/           # Canonical model definitions
├── providers/        # Inference provider definitions
├── mappings/         # Provider-model links with pricing
│   ├── anthropic/
│   ├── openai/
│   ├── together-ai/
│   └── ...
└── schemas/          # JSON Schema (Draft 7) for validation

Every YAML file is validated on pull request via GitHub Actions:

YAML syntax check
JSON Schema conformance
Referential integrity (mappings must reference existing models and providers)
Duplicate ID detection

Nothing merges without passing all four checks.

2. Platform Layer

The platform consumes registry data and adds operational intelligence:

REST API (api.openmodels.run) — model discovery, provider comparison, telemetry endpoints
Web Interface (openmodels.run) — search, browse, compare with Command Palette and ecosystem graph
Telemetry Workers — health probes every 5 minutes, latency probes every 15 minutes

Core Concepts

The registry is built around three entities:

┌─────────┐         ┌───────────┐         ┌──────────┐
│  Model  │◄────────│  Mapping  │────────►│ Provider │
└─────────┘         └───────────┘         └──────────┘
  (what)          (pricing, limits)         (where)

Model — a canonical LLM definition (e.g., DeepSeek V3, Claude Opus 4.6). Describes capabilities, modalities, context window, and licensing. Vendor-neutral.

Provider — an inference service (e.g., Together AI, Groq). Describes API endpoint, auth type, regions, and compatibility format.

Mapping — the glue. Connects a model to a provider with specific pricing, rate limits, and available regions.

This creates a many-to-many relationship: one model can be served by multiple providers at different price points, and one provider can serve dozens of models.

Example: Llama 4 Scout across providers

Provider	Input (per 1M tokens)	Output (per 1M tokens)	RPM
DeepInfra	$0.06	$0.18	600
Groq	$0.11	$0.34	30
Cerebras	$0.60	$0.60	30

Same model, three providers, 10x price difference. That's the kind of visibility the registry provides.

What a Model Definition Looks Like

id: deepseek-v3
name: DeepSeek V3
description: DeepSeek's third-generation large language model with mixture-of-experts architecture.
capabilities:
  - chat
  - completion
  - function-calling
  - code-generation
  - reasoning
modalities:
  - text
  - code
context_window: 128000
licensing: other
created_at: "2024-12-01T00:00:00.000Z"
updated_at: "2025-01-15T00:00:00.000Z"

What a Mapping Looks Like

model_id: deepseek-v3
provider_id: together-ai
provider_model_name: deepseek-ai/DeepSeek-V3
pricing:
  input_per_million: 0.90
  output_per_million: 0.90
  currency: USD
rate_limits:
  requests_per_minute: 600
  tokens_per_minute: 1000000
context_window_override: null
available_regions:
  - us-east-1
created_at: "2025-01-01T00:00:00.000Z"
updated_at: "2025-01-01T00:00:00.000Z"

Telemetry

The platform continuously monitors provider health and performance:

Metric	Interval	Retention
Health status (up/down)	Every 5 min	30 days
Time to first token (TTFT)	Every 15 min	30 days
Total response time	Every 15 min	30 days
Availability (uptime %)	Computed	Rolling 7 days

When a user queries ranked providers for a model, the API computes a composite score:

Factor	Weight
Uptime (7-day rolling)	40%
Median latency (TTFT)	30%
Price per million tokens	20%
Median total response time	10%

This means the API can answer: "Which provider should I use for DeepSeek V3 right now?" — factoring in live performance, not just listed specs.

API

The public API at api.openmodels.run provides model discovery, provider comparison, and telemetry data. Key endpoints:

GET /api/models                        # Search and list models
GET /api/models/:id/providers          # Providers for a model with pricing
GET /api/models/:id/compare            # Side-by-side provider comparison
GET /api/telemetry/ranked/:model_id    # Ranked providers by live performance
GET /api/search                        # Unified search across the registry

Full API reference: docs.openmodels.run/api-reference

Web Interface

The web app at openmodels.run provides:

Model search with sort by name, recency, context window, or provider count
Provider comparison view (pricing, latency, uptime side-by-side)
Command Palette (Cmd+K / Ctrl+K) for instant global search
Interactive ecosystem graph (node visualization of model-provider relationships)
Popular models section with relevance-based ranking
Category navigation by capability, modality, and license
Dark/light mode
Mobile-responsive layout

Coverage

The registry covers models from OpenAI, Anthropic, Google, Meta, DeepSeek, Mistral, xAI, Alibaba, Microsoft, NVIDIA, Cohere, Moonshot, Zhipu, MiniMax, and others — across 30 inference providers including first-party APIs and third-party platforms like Together AI, Groq, DeepInfra, Fireworks, SambaNova, Nebius and Scaleway.

Full model and provider lists are available in the registry repository.

Contributing

Adding a model, provider, or mapping is a pull request:

Fork the repository
Create a YAML file following the schema
Run python validate_registry.py locally
Open a PR — CI validates automatically
Merge after review

All IDs use kebab-case (deepseek-v3, together-ai). All timestamps are ISO 8601. The schemas enforce structure, so invalid data never enters the registry.

Current Focus

Telemetry reliability and probe coverage
Provider ranking accuracy
OpenAPI specification for the public API
Expanding ecosystem coverage (models, providers, regions)

Compare LLM API Costs Across Providers

Made Büro — Wed, 06 May 2026 12:30:44 +0000

Choosing a model shouldn't mean opening five browser tabs and doing math. But that's the current state of things, every provider has its own pricing page, its own token definitions and its own fine print.

llmprices is a CLI that cuts through this. Give it a prompt or a token count, and it returns a sorted cost comparison across providers in seconds. There's also a web version at llmcost.run.

# Find best price-to-quality ratio
llm-cost calc "Build a Python REST API" --sort value

# Filter by capability tier
llm-cost list --tier advanced

# Combine both
llm-cost calc "Code task" --tier advanced --sort value --top 5

The Problem

LLM pricing is more complex than it looks at first glance.
Input and output tokens are priced separately, and the gap between them is significant output can cost anywhere from 3x to 20x more than input depending on the provider. Context window size affects whether a model is even viable for a given task, regardless of its per-token rate. And perhaps most importantly, the cheapest model isn't always the best choice: a $0.06/1M input model is excellent for classification pipelines, but the wrong tool for complex reasoning or code generation.

There's no neutral, up-to-date source that puts all of this in one place. llmprices is an attempt to be that.

Core Commands

pip install llmprices

calc
Estimates the cost of a prompt across all models and sorts by price.

llm-cost calc "Build a Python REST API" --output 500

╭── Cost estimate · 7 input + 500 output ───────────────────────────────────╮
│  #  Provider      Model                Total cost    vs cheapest           │
│  1  Mistral AI    Mistral Small 3.2    $0.000090     cheapest              │
│  2  DeepSeek      DeepSeek V4 Flash    $0.000141     1.6x                  │
│  3  Google        Gemini 2.5 Flash-L   $0.000200     2.2x                  │
│  4  xAI           Grok 4.1 Fast        $0.000251     2.8x                  │
│  5  OpenAI        GPT-5.4 Nano         $0.000626     7.0x                  │
│  6  Anthropic     Claude Haiku 4.5     $0.002507     27.9x                 │
│  7  Google        Gemini 3.1 Pro       $0.006014     66.8x                 │
│  8  OpenAI        GPT-5.5              $0.015035    167.1x                 │
╰───────────────────────────────────────────────────────────────────────────╯

You can pass a raw text prompt (tokens are counted automatically) or skip it and specify token counts directly:

llm-cost calc --input 4000 --output 1000
llm-cost calc --input 10000 --output 2000 --top 5 --provider google

compare
Direct head-to-head comparison between specific models.

llm-cost compare gpt-5-5 claude-opus-4-7 gemini-3-1-pro

llm-cost compare claude-sonnet-4-6 gpt-5-4 gemini-3-flash --input 5000 --output 1000

llm-cost compare gpt-5-5 claude-opus-4-7 --prompt "Explain how transformers work"

list
Browse the full catalog with filtering and sorting.

llm-cost list
llm-cost list --provider anthropic
llm-cost list --sort output
llm-cost list --search gemini

Efficiency Tiers

Sorting by price is useful, but it doesn't account for capability. A budget model ranked first for cost might produce unusable output for a complex task. To address this, models are grouped into four tiers based on capability level — independently of price.

Flagship — GPT-5.5, Claude Opus 4.7, o3. Suitable for complex analytical tasks, critical decision-making, and high-quality creative work where output quality matters more than cost.

Advanced — GPT-5.4, Claude Sonnet 4.6, DeepSeek R1, o4 Mini. A solid default for most professional workloads: code generation, detailed analysis, structured output.

Standard — GPT-5, Claude Haiku 4.5, Gemini Flash, Mistral Large 3. Reliable for everyday tasks, basic text processing, and simple question-answering at scale.

Budget — Mistral Small 3.2, Command R7B, DeepSeek V4 Flash. Best for high-volume pipelines, classification, and prototyping where task complexity is low.

llm-cost list --tier budget
llm-cost calc "Code review" --tier advanced --sort value
llm-cost calc "Complex analysis" --tier flagship --sort value

Some Things the Data Makes Clear

Running calc across different workloads reveals a few patterns worth keeping in mind.

The cost spread is wider than most people expect. For the same token count, the cheapest available model is often 100–200x less expensive than the most capable one. The vs cheapest column in the output makes this concrete rather than abstract.

At scale, tier selection matters more than model selection within a tier. For a pipeline processing 1 million classification requests at 100 input + 50 output tokens, budget-tier models land at $11–28 total. The same volume on GPT-5.5 costs around $2,000. For tasks that don't require flagship reasoning, that's a 99%+ cost reduction with no meaningful quality tradeoff.

Context window size is a hidden cost variable. A model with a lower per-token rate but a 128K context limit can end up more expensive than a pricier 1M-context model once you account for chunking logic, additional requests, and the engineering overhead of working around the constraint.

The practical workflow is: start with advanced, drop to budget if the output quality is sufficient for the task and escalate to flagship only when the task genuinely requires it.

Contributing

Prices are stored in a plain YAML file at llm_cost/data/prices.yaml. Adding a new model takes four fields:

my-new-model:
  name: My New Model
  input: 1.50      # $ per 1M input tokens
  output: 6.00     # $ per 1M output tokens
  context: 200000  # context window in tokens

PyPI: pypi.org/project/llmprices
Web: llmcost.run
Source: github.com/madeburo/llmcost

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.