Marc Lou shipped a CLI for DataFast from 30,000 feet this week.
He posted about it on Tuesday, saying AI shipped funnels to the CLI while he was 30,000 feet in the air, and the next day he dropped a checklist of what makes a SaaS "AI-first." Open all your API endpoints. Add an llms.txt and markdown docs. Build a CLI. Then MCP, generative UI, paywall onboarding.
That phrase, "AI-first SaaS," has been everywhere on indie X this week. I'm trying to figure out what it actually means before I add any of it to Slap's roadmap. So I read what people are shipping, and here is what I found.
What "AI-first SaaS" actually means
The short version. Your software has to be readable by AI agents, not just by humans on a browser tab.
That means a few specific things in 2026:
- A clean public API that does the same things your UI does
- An llms.txt file at your root that tells AI crawlers what your product is and how to use it
- Markdown versions of your docs at predictable URLs
- An MCP server (Anthropic's Model Context Protocol) so AI assistants can call your product as a tool
- A CLI for the same reason. Agents drive CLIs better than they drive web UIs
None of this is wild. Most of it is stuff your engineering team already half-built. The shift is that you are now treating Claude, Cursor and the next agent that ships as a customer segment.
Marc Lou's public checklist
Lou posted the DataFast checklist on May 12. He listed five things, with checks and empty boxes:
Open all API endpoints (done)
llms.txt and markdown docs (done)
CLI (done, new)
MCP (todo)
Generative UI (todo)
Onboarding with paywall (todo)
Three done. Three left. The post pulled 383 likes. Most indie hackers I follow either retweeted it or quietly added it to their own Notion doc.
A lot of the reaction was "okay but does this actually move revenue?" Lou has not shared MRR delta from the change yet. He is calling it a positioning bet. DataFast wants to be the analytics tool that agents reach for when they are working in someone's codebase.
The piece big SaaS is refusing to ship
Here is the part that surprised me. Pieter Levels spent this week trying to build an AI accounting reconciler. He has been posting publicly about it. The thing kept hallucinating expenses that were not there. Then he hit the real wall. Xero, the big incumbent, told him they would "NEVER" add reconciliation via API.
Two days later he posted:
Tax and accountancy software and bookkeeping industry have perverse incentives to keep the tax code and bookkeeping hard so you have to keep paying a lot for their software and to hire them. If they let AI just do it via their APIs, their value would go to $0 fast!
That is the gap. Big SaaS is built on the idea that humans pay for software that humans use. AI agents being able to use the same software for fractions of a cent per call breaks that model. So companies like Xero are closing doors. And small indie hackers, who do not have that fortress to defend, are doing the opposite. They are kicking every door open.
It is a real wedge. Not a hack. If you are building a 1-3 person SaaS and your competitor is a public company that depends on per-seat pricing, exposing your API to agents is an actual moat you can ship in a weekend.
What I would ship if I were starting today
For Slap, I am trying to be honest about what is worth doing right now versus what is just nice on a checklist. Here is the short version of how I would rank Marc's list if I were starting in 2026.
Ship this week. llms.txt and markdown docs. It is a half-day of work. It costs you nothing. If an indie dev asks Claude "what does Slap do," the answer is your file, not whatever ChatGPT scraped off your landing page last quarter.
Ship this month. A public API for the read-only side of your product. Does not need to be everything. Pick the thing a developer would actually want to script against. For Slap that is "give me the top X posts in this niche right now." For Marc that is "give me last week's traffic for this domain."
Ship when you have a paying customer asking. MCP server, CLI, generative UI. These are real but they take real time. Do not build them on speculation. Wait until one paying user emails and says "can your tool do this from my agent."
Honestly maybe skip. "Onboarding with paywall" for agents. This one is in Marc's list and I get the logic. Make agents pay to use you. But for most indie SaaS the agents using your API are not the buyers, the humans paying the agents are. Sort out the human pricing first. The agent-pricing question is a 2027 problem.
The question your customer might not be asking yet
Here is the rough part. Most of my Slap users right now want to scroll an iOS app and find X posts to reply to. They are not asking me to expose an MCP server. They are not asking for a CLI. They are not asking for llms.txt.
If I add all this stuff because Marc Lou added it, I am building for indie X, not for my actual customers. And that is the trap a lot of us fall into. You read a thread, you get hyped up, than the next week the high leaves and you have shipped three features nobody asked for.
The honest filter is this. Does any of this remove a thing that is currently breaking for a paying customer? For Slap right now the answer is probably "the llms.txt and markdown docs part, because indie devs asking AI about us is a real funnel." The rest is on the wait-and-see list.
For other people building developer-facing tools, analytics, content APIs, infra, the case is way stronger. Marc's checklist is doing real work in his niche. It might do real work in yours. Just do not ship it because it looks like the next thing.
If you want the version of this conversation that is more about X distribution than product surface area, here are my notes on what worked for audience growth in May 2026 and the seven indie SaaS growth tactics I keep coming back to.