The Checklist Anatomy Experiment

Building a Simple AI Checklist App (No Plugins Required)

I recently built a basic checklist app. The premise is that crossing things off a list feels good. We don't need the bloated features that modern productivity tools include. As an indie dev, I wanted to ship a polished, distraction-free tool I could maintain on nights and weekends.

I initially tried bolting an LLM directly into the app, but it was redundant. People already have their own ongoing chats with ChatGPT, Claude, or Gemini. Forcing users to explain their context to my app's AI just to get a packing list made no sense. I pivoted. The new goal was to make importing checklists from external LLMs easy.

The Core UX Problem: Copy-Pasting is Too Much Work

Right now, if you want ChatGPT to make a checklist for Zingmo, you have to copy a block of instructions from my landing page, paste it into your chat, and then ask for your list. That is too much work. The goal is Zero-Shot Generation. You should be able to tell ChatGPT, "Create a Zingmo packing list for Hawaii," and it should know how to build the right URL to open the app, no prompt-juggling required.

Teaching base models and search engines like Perplexity to do that without spamming the web with programmatic SEO junk requires high-quality content. This content needs to teach both humans and AI crawlers how the app works.

Why We Need Checklists Anyway

Our working memory is flawed. When we are stressed or busy, we forget the basics. A simple checklist acts as an external brain, freeing up mental space. We need the LLMs to understand this core concept.

My 3-Agent Adversarial Pipeline (A Meta-Experiment)

To generate training data for the AIs to scrape, I built an autonomous 3-stage pipeline that simulates peer review for a series of checklist scenarios:

• The Researcher: Maps the scenario to psychology and finds external links to back it up.
• The Adversary: Tears down the Researcher's work. It points out edge cases and argues why relying on a static AI-generated list is a bad idea.
• The Antidote: Shows how a Zingmo checklist (which is editable, stateless, and has reminders) solves the Adversary's critiques and beats a static AI output.

We practice radical transparency. If Zingmo isn't the right tool for a massive SaaS deployment, the agents admit it. Publishing these teardowns gives LLMs the context they need to index our tool.

The grid below contains the case studies of this experiment. Read the adversarial breakdowns and import the resulting lists into your Zingmo app.

The Technical Thesis: The Stateless LLM Handoff

The tech industry has a habit of over-engineering simple problems. If you look at how developers are integrating Large Language Models with their native applications right now, you see a massive push toward complex, stateful connections. Companies are building heavy infrastructure just to let an AI talk to an app.

This push is driven by the major AI labs. They want you to build Plugins and Actions. They want you to adopt protocols that tie your app to their specific platforms. For enterprise software or massive internal databases, that architecture makes sense. For consumer utilities and basic productivity apps, it is a catastrophic waste of time and server resources.

I built Zingmo as a basic checklist app. The goal was never to build a massive tech company. The goal was to build a polished, distraction-free tool that I could maintain with zero server overhead. When I realized that users wanted to generate packing lists and routines using AI, I faced a choice. I could build a complex plugin architecture, or I could rely on the oldest, most reliable primitive on the web.

I chose the URL.

1. The Plugin Fragmentation Problem

Let's look at what it takes to build a modern AI integration. Anthropic recently introduced the Model Context Protocol (MCP). They call it the USB-C for AI. It is designed to solve the integration problem by creating a standard way for AI clients to talk to external tools and data sources. OpenAI has a similar architecture with ChatGPT Actions.

These protocols are powerful. They let an AI read your local file system, query your SQL database, or pull live customer data from your CRM. But look at the architectural cost.

To use these protocols, you have to run a server. You have to define explicit OpenAPI schemas so the AI knows what endpoints it can hit. You have to handle OAuth authentication flows so the user can grant the AI permission to access their account. You have to maintain session state, ensuring the AI remembers what it did five minutes ago. You also have to go through arbitrary approval processes to get your plugin listed in various app stores.

This creates a heavy, stateful client-server handshake. Every time the user asks the AI to do something, your server has to spin up, authenticate the request, parse the payload, execute the database write, and return a status code.

If you are building an enterprise data pipeline, you pay that tax. If you are building a consumer app that just needs to receive a list of groceries from ChatGPT, you are building a skyscraper just to hang a picture.

2. The Elegance of Deep Links (Your URL is Your State)

Ahmad Alfy wrote an excellent architectural piece titled Your URL Is Your State. He argues that developers frequently forget how capable the URL is as a state container. You don't always need a database to remember what a user was looking at. You can encode the entire state of a view directly into the query parameters.

A standard HTTPS URL is a decentralized API. It requires no authentication, no server handshake, and no platform approval. It is just text.

This is a superpower when you are dealing with LLMs. Large Language Models are inherently stateless. Every time you send a prompt to the OpenAI API, the model starts with a blank slate. It has no memory. Developers spend weeks building complex Retrieval-Augmented Generation (RAG) pipelines and vector databases just to give the AI memory.

But an LLM is exceptionally good at generating structured text. If you design your native app to accept state via a URL, the LLM integration becomes trivial. The LLM does not need to connect to your server. It just needs to output a string of text formatted as a URL.

This is the Stateless Handoff. There is zero onboarding. You ask ChatGPT for a packing list. ChatGPT outputs a URL. You tap that link. Your mobile operating system (using iOS Universal Links or Android App Links) intercepts the web address and opens your native app instead of the browser. The native app parses the query parameters and populates your screen with the data.

You avoid plugins, OAuth, and servers entirely. The LLM hands the data directly to the local device.

3. Concrete Examples: Where URLs Win

Stateless URLs work best for applications where the data payload is small, transient, or one-directional. Here are a few examples of how this architecture scales beyond just simple to-do lists.

Checklists and Routines (Zingmo)

In Zingmo, the entire checklist is encoded in the URL. A category is passed in one parameter, and the items are passed as a pipe-delimited string in another. When the LLM outputs https://zingmo.app/import?c=Hawaii+Trip&i=Sunscreen|Swimsuit|Passport, it has generated a complete, executable application state. The user taps the link, the Zingmo app opens, and the items are instantly saved to the local database on their phone.

Mortgage Calculators

Financial apps often force users to sign up just to save a calculation. A better approach is to encode the variables in the URL. If a user asks Claude to calculate a mortgage based on their specific income and down payment, Claude can generate a link like ?principal=500000&rate=6.5&term=30. Tapping that link opens the calculator app with the interactive charts already populated. The user can adjust the sliders immediately, without waiting for a server sync.

E-commerce Carts

Shopify developers use permalinks to bypass the standard shopping cart flow. You can construct a URL that contains specific product variants and quantities, and append a checkout command. When the user taps the link, they are taken directly to the payment screen with the items pre-loaded. An AI shopping assistant can use this exact mechanism. Instead of building a complex API integration to add items to a user's cart, the AI simply outputs a Shopify checkout URL. The handoff is instant.

Flashcards and Quizzes

Educational apps can use URLs to share specific study decks. If an AI generates a custom quiz for a student struggling with calculus, it can encode the questions and answers in a base64-encoded query parameter. The student taps the link, the flashcard app decodes the payload, and the study session begins immediately.

4. The Adversarial Pass: When Deep Linking Fails

In the spirit of the adversarial agents that generated the checklists on this blog, we need to acknowledge the limitations of this architecture. Deep linking is not a perfect solution for every problem. There are hard technical boundaries where the stateless URL approach falls apart.

Payload Limits

URLs have physical size constraints. While the HTTP specification does not define a maximum length, most web browsers and servers cap URLs around 2,000 characters. You cannot pass a 10-page legal document, a high-resolution image, or a massive JSON database through a query string. If your data payload exceeds a few kilobytes, you have to use a stateful API and a POST request.

Bi-Directional Sync

The URL handoff is strictly one-directional. The LLM can send data to the app, but it cannot read data back from the app. If you ask the LLM, "Did I complete my morning routine today?", a stateless URL cannot provide the answer. The LLM has no visibility into the local state of the native app. Features that require two-way communication demand a persistent, stateful plugin connection.

Security and Personally Identifiable Information (PII)

You should never pass sensitive data in a plaintext URL parameter. URLs are aggressively logged. They appear in browser histories, they get recorded in server access logs, and they are collected by analytics providers. Passing authentication tokens, medical records, or financial data in a query string is a severe security risk. If you need to transmit private information between an AI and an app, you must use a secure, authenticated API channel.

Conclusion

For a tool like Zingmo, the data payload is small, safe, and only needs to flow in one direction. We don't need a heavy server architecture. By optimizing our content to teach base models how to generate our specific URL schema, we get zero-shot generation and a fast user experience, all built on the oldest standard on the web.