If you are building a SaaS product right now, there is a good chance users will eventually want Claude, Cursor, or another AI client to talk to it directly. MCP is the cleanest way to do that, but the interesting work starts after the tools are defined. The hard part is deciding how the server should be deployed, how authentication should work, and how much setup friction you are willing to push onto the user.

This guide is about that part. It explains what MCP is, why remote MCP matters for SaaS products, the different ways you can ship it, and what it takes to get to the version most teams actually want: a hosted integration where the user signs in and approves access instead of generating and pasting a token.

What MCP Actually Is

MCP is a protocol that lets AI clients interact with external systems in a structured way. Instead of hoping a model can scrape your web app, infer your API shape, and guess the right mutation flow, you expose a smaller and more explicit surface: tools, resources, and sometimes prompts. The AI client does not need to know the full internals of your product. It only needs to know what operations you have chosen to expose and how to call them safely.

Under the hood, the important distinction is usually transport. A local MCP server commonly uses stdio. A remote MCP server uses HTTP, which is what makes hosted auth, hosted discovery, and normal SaaS-style onboarding possible. For a SaaS product, that usually means operations like reading data, searching, creating records, updating records, or triggering workflows. If those capabilities already exist inside your application, MCP is often the shortest path from “this works internally” to “an AI client can use this with a stable contract.” That is why MCP matters. It reduces scraping, reduces prompt glue, and gives you a narrower place to enforce auth, validation, and limits.

Why Remote MCP Matters for SaaS Products

A local MCP server is fine for internal tools, prototypes, or products aimed only at technical users. A hosted SaaS product, though, usually wants a remote MCP server as the end state because the alternative is to ship part of your integration story onto the user’s machine. Once that happens, your product inherits local runtime issues, PATH issues, install issues, and credential-management issues that have nothing to do with the core value of the app.

Remote MCP keeps the business logic in your infrastructure, where you can monitor it, rate-limit it, update it, and keep it aligned with the rest of your product. Just as importantly, it lets you move toward a normal onboarding flow. That matters because most users do not actually want “MCP support.” They want to connect an AI client to your app without turning themselves into part-time integration engineers.

The Three Practical Ways to Ship MCP

If you are building this today, you usually end up choosing between three models.

1. Local stdio server

This is the fastest way to get something working. The user runs a local process, often through npx or a downloaded binary, and the AI client talks to it over stdio. This model is excellent for internal tooling and for technical users who are comfortable with local setup. It is also the easiest model to document because you are only solving for one environment at a time.

If you are building in TypeScript, the normal starting point is the MCP TypeScript SDK with StdioServerTransport. In practice, that usually means something like:

npm install @modelcontextprotocol/sdk zod

For customers, onboarding looks like this:

1. Install your MCP package or binary.

2. Add a local command to their MCP client.

3. Run that command on their own machine whenever the client connects.

The downside is that your onboarding now depends on the user’s machine. Node versions, binary distribution, shell quirks, and local config all become part of your product whether you wanted them or not.

2. Remote MCP with manual token auth

This is a common middle step. The server is hosted, which is a big improvement, but the user still has to generate a token and paste it into the client. Depending on the client, they may also still need a local bridge to reach the hosted server. This version can already be useful, especially if your target users are technical and motivated, but it still leaks setup friction into the experience.

For the hosted server itself, you can still use the MCP TypeScript SDK and switch to Streamable HTTP instead of stdio. If your target client only knows how to spawn local commands, the usual bridge is mcp-remote:

npm install @modelcontextprotocol/sdk zod
npm install -g mcp-remote

or, if the user is launching it ad hoc:

npx mcp-remote https://yourapp.com/dashboard-mcp

For customers, onboarding usually looks like this:

1. Create a token in your product.

2. Add your hosted MCP URL or a local mcp-remote bridge command.

3. Paste the token into the client config.

3. Remote MCP with hosted OAuth and tokenless onboarding

This is the model most SaaS teams eventually want. The user adds a connector URL, signs in, approves access, and starts using the integration. There is no manual token creation, no pasted bearer secret, and no local helper process just to reach your hosted endpoint. It is the cleanest version from the user’s point of view, and it is usually the hardest one to build because it forces auth, discovery, deployment, and product UX to line up cleanly.

Implementation-wise, this is still the same remote server shape. The difference is that you finish the auth layer. In practice that usually means:

npm install @modelcontextprotocol/sdk zod

and then building the OAuth and discovery routes around that server instead of shipping manual token setup.

For customers, onboarding becomes:

1. Open the connector UI in the client.

2. Paste your hosted MCP URL.

3. Sign in to your product.

4. Approve access.

Model Useful package(s) How customers onboard Main downside Local stdio @modelcontextprotocol/sdk with stdio transport Install package or binary, add local command Local runtime and config become part of your product Remote MCP + manual token @modelcontextprotocol/sdk for the server, mcp-remote when a client still expects local stdio Add hosted URL or bridge command, then paste token Credential and bridge friction remain Remote MCP + hosted OAuth @modelcontextprotocol/sdk with Streamable HTTP plus your OAuth layer Add hosted URL, sign in, approve access Hardest to implement cleanly

A Minimal Way to Start

If you want a sane implementation path, do not start with OAuth. Start by proving that your tool surface is useful locally, then move the exact same operations behind a hosted transport, and only then add the auth and discovery layers.

A minimal local TypeScript server looks like this:

import * as z from "zod/v4";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new McpServer({
  name: "my-server",
  version: "1.0.0",
});

server.registerTool(
  "greet",
  {
    description: "Test tool",
    inputSchema: {
      name: z.string(),
    },
  },
  async ({ name }) => ({
    content: [{ type: "text", text: `Hello, ${name}!` }],
  })
);

const transport = new StdioServerTransport();
await server.connect(transport);

That does not get you a hosted connector, but it does answer the first question that matters: are your tools coherent enough that an AI client can do something useful with them?

Once the local version is working, the recommended build order is:

1. Keep the same tool definitions and move them behind Streamable HTTP.

2. Give the server one clean public MCP URL.

3. Add the unauthenticated 401 challenge.

4. Publish protected-resource and auth-server metadata.

5. Add consent and token issuance.

6. Test the entire flow through a public tunnel before calling it done.

That order matters because most remote MCP projects do not fail on the first tool. They fail in the layers around it.

Step 1: Define the Smallest Useful Tool Surface

The tool layer is rarely the hardest part, but it is still where the project should start. The trick is not to expose every internal operation you have. Start with the smallest set of tools that covers a real workflow end to end. A good MCP surface should feel deliberate because it needs to map to things users actually want the model to do, not to your raw internal API topology.

If your product is documentation software, the surface might look like: list docs, inspect a manifest, pull content, push content, publish. If your product is a CRM, it might be: search contacts, fetch an account, create a note, update a stage. The details vary, but the rule stays the same: expose coherent workflows, not just miscellaneous RPC endpoints.

Step 2: Give the Server a Real Public URL

Once you move beyond local development, the MCP URL becomes part of the integration design. This is easy to overlook because teams often expose whatever internal-looking route already exists, then wonder why the integration still feels unfinished. A clean public path does not solve protocol problems, but it does help make the feature feel like a first-class product surface instead of an implementation detail that escaped from your router.

In practice, that means preferring something like:

https://yourapp.com/dashboard-mcp

over something like:

https://yourapp.com/api/internal/v1/mcp

The first reads like a capability. The second reads like a leak. Users notice this even when they do not say it out loud.

As one concrete example, DocsAlot moved its write-capable dashboard MCP flow onto a canonical public path, https://docsalot.dev/dashboard-mcp, and kept the older internal-looking route only as a compatibility alias. That made the integration easier to explain, easier to document, and easier to recognize as a product surface instead of an API accident.

Step 3: Implement the MCP Endpoint Like a Real Transport

Current remote MCP servers should behave like proper HTTP transports, not just “an API route that happens to accept JSON.” In practice, that means implementing the Streamable HTTP shape cleanly. The server exposes one MCP endpoint. Clients send JSON-RPC messages to it over HTTP POST. The server can reply with normal JSON for simple requests or text/event-stream when it wants to stream messages, progress, or notifications back to the client.

That one detail matters more than it sounds. A lot of integrations feel flaky because the tool layer exists, but the endpoint still behaves like an ad hoc RPC surface rather than the transport the client expects.

At a minimum, your endpoint should be able to handle something like this:

POST /dashboard-mcp
Accept: application/json, text/event-stream
Content-Type: application/json
MCP-Protocol-Version: 2025-06-18

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{...}}

If you want stateful sessions, return an Mcp-Session-Id during initialization and require that header on subsequent requests. If you do not want sessions, you can stay stateless, but make that choice intentionally. Either way, the endpoint should be acting like an MCP transport, not a loose collection of tool handlers.

Step 4: Make the Unauthenticated Endpoint Useful

If you want tokenless onboarding, the unauthenticated endpoint cannot just say “missing token” and stop there. It has to tell the client how to continue. In practice, that means returning a 401 with a WWW-Authenticate header that points to your protected-resource metadata.

GET /dashboard-mcp

401 Unauthorized
WWW-Authenticate: Bearer realm="yourapp", resource_metadata="https://yourapp.com/.well-known/oauth-protected-resource/dashboard-mcp"

That resource_metadata URL is where the client learns what resource it is trying to access and how to find the rest of the authorization flow. Once you have this in place, the endpoint stops being “something that eventually wants a token” and starts behaving like a remote integration surface that knows how to onboard a client properly. This one step is where many half-finished remote servers reveal themselves, because the hosted endpoint is present but the hosted onboarding path is still missing.

Step 5: Publish the Discovery Documents and Support Client Registration

The 401 challenge is only the start. A client still needs to discover two things:

1. Which authorization server is responsible for this MCP resource.

2. Which authorization, token, and registration endpoints that server exposes.

That usually means publishing:

• protected-resource metadata for the MCP URL

• authorization-server metadata for the OAuth server

• dynamic client registration, if you want new MCP clients to onboard without pre-created client credentials

The shape looks roughly like this:

// /.well-known/oauth-protected-resource/dashboard-mcp
{
  "authorization_servers": ["https://yourapp.com/oauth"]
}

// OAuth server metadata
{
  "issuer": "https://yourapp.com/oauth",
  "authorization_endpoint": "https://yourapp.com/oauth/authorize",
  "token_endpoint": "https://yourapp.com/oauth/token",
  "registration_endpoint": "https://yourapp.com/oauth/register"
}

The exact metadata shape depends on your auth server, but the practical point is simple: a client should be able to start from your MCP URL and discover the rest without hardcoded tribal knowledge. If you skip dynamic client registration, every new client either needs a pre-provisioned client ID or a manual setup screen. That is usually where “tokenless onboarding” quietly turns back into a configuration project.

Step 6: Treat Discovery Routes as First-Class Routes

This is where a lot of teams lose time. The main MCP URL works, the app is up, and yet the connector still fails because the client is probing issuer-specific /.well-known/... URLs that your main routing stack is not handling correctly. Instead of returning JSON metadata, those paths often return HTML, redirects, or some generic page response because they fell through to the wrong handler.

The fix is not complicated, but it needs to be explicit. Define the discovery routes directly and test them directly. Do not assume your framework routing will get them right by accident. If you are using Next.js, Rails, Laravel, or anything else with a large implicit routing layer, hit each discovery endpoint with curl before you trust the connector flow. If those routes are wrong, the rest of your onboarding work never gets a chance to matter.

Step 7: Reuse Your Existing Login System, but Add a Real Consent Layer

If your SaaS product already has a working sign-in system, the MCP OAuth flow should usually land inside that system. This is one of the biggest advantages of hosted onboarding. The user does not have to think about “API credentials” as a separate universe. They just sign in to the product they already know and approve access.

But a normal login page is not enough. You still need a consent step that is specific to the MCP resource and its scopes. That is where you decide whether the connector can read, write, publish, delete, or trigger actions. For a lot of SaaS products, the right move is to reuse the same user session and identity system while adding a separate grant model for the MCP server itself.

This is also the point where subtle bugs tend to show up, because your app auth, your public domain, your redirect handling, and your MCP metadata all need to agree. When they do not, you get failures that look almost healthy. The endpoint responds. The auth page opens. Sign-in appears to work. The callback still fails because a cookie, origin, or redirect assumption broke somewhere in the chain.

The rule here is simple but unforgiving: the connector flow needs one stable public identity. If the public host changes halfway through the handshake, you are going to get confusing failures.

Step 8: Validate Resource Indicators and Token Audience

This is one of the more technical parts of the current MCP auth model, and it is worth implementing correctly. The client should request a token for a specific MCP resource, not just “whatever this auth server hands out.” In OAuth terms, that means carrying a resource parameter that points at the canonical MCP server URI.

In practice, the auth and token requests end up looking more like this:

GET /oauth/authorize?...&resource=https%3A%2F%2Fyourapp.com%2Fdashboard-mcp
POST /oauth/token
resource=https://yourapp.com/dashboard-mcp

On the server side, you should not just mint a token and hope for the best. Validate that the token was issued for the MCP resource that is receiving it. If your product hosts multiple MCP surfaces, or if your auth infrastructure is shared across products, this becomes a real security boundary rather than a theoretical nicety.

If you skip this, you are much closer to “opaque bearer string that happens to work” than to a clean remote MCP implementation.

Step 9: Protect the HTTP Edge

Most of the painful failures are not in the tool handler itself. They are in the edge conditions around the HTTP transport. There are a few checks worth treating as mandatory:

1. Validate the Origin header on incoming HTTP connections.

2. Never accept access tokens in query strings.

3. Return 401, 403, and 400 distinctly so clients can tell auth failure from permission failure from malformed requests.

4. Be strict about the MCP endpoint shape and headers, especially on initialize and token-bearing requests.

The Origin validation piece is easy to miss, but it matters for local and browser-adjacent deployments because it helps defend against DNS rebinding-style problems. If you are hosting a remote MCP server on the public internet, that is part of the real implementation, not just optional hardening for later.

Step 10: Budget for Tunnel-Based Testing

Remote connectors are awkward to test locally because “local” is only part of the truth. For the full loop to work, the client still needs a publicly reachable HTTPS endpoint. That usually means running your app locally and exposing it through a tunnel, then aligning your app base URL and callback URLs to that temporary hostname.

This is where a lot of real bugs show up. Social sign-in providers reject callback mismatches. Discovery URLs resolve differently than they do in production. Session cookies behave differently across hostnames. If you are testing with Claude custom connectors specifically, there is one more wrinkle: the connection comes from Anthropic’s cloud, not from the Claude Desktop app on your own machine. If you only test the app on localhost, you will miss some of the most important onboarding failures. In practice, the first fully working tunnel-based test tells you more about your real connector than a week of localhost confidence.

The simplest way to do this is with ngrok. Their tunnels documentation is also worth reading because it explains exactly how the public URL is forwarded back to your local port.

If your app is running on port 3000, the basic setup is:

brew install ngrok/ngrok/ngrok
ngrok config add-authtoken <your-ngrok-token>
ngrok http 3000

Once that is running, ngrok gives you a public HTTPS URL. Use that hostname for the parts of your auth flow that care about the public origin:

1. your app’s public base URL

2. your MCP URL

3. your OAuth callback allowlist

4. any social sign-in callback settings you depend on

So the practical advice is: treat tunnel-based auth testing as part of the feature, not as cleanup work after the feature. It is not cleanup. It is where the real system finally reveals itself.

What to Expect to Go Wrong

The hardest bugs will probably not be in your tool handlers. They will be in the edges around them. Discovery routes returning HTML instead of JSON is common. Public origin mismatches are common. Redirect and cookie problems are common. Time handling inside auth flows can also surprise you more than it should, especially if you compare expiration values across different layers and different assumptions about timestamps.

This is one reason MCP can feel deceptively simple at the start. The first tool call might be easy. The part where a real desktop client discovers the server, signs in, stores the authorization state correctly, and comes back later for the second tool call is where you find out whether the integration is actually finished.

A Good End State

If you are building a remote MCP server for a SaaS product, a good end state looks like this:

1. The public URL is clean and stable.

2. The tool surface is narrow and intentional.

3. Discovery and protected-resource metadata are explicit.

4. The user signs in through your normal app auth.

5. The user approves access instead of creating a token manually.

6. The whole flow works without local runtime setup.

That is the version that reduces friction. It is also the version that starts to feel less like a protocol demo and more like a real product feature.

MCP itself is not the hard part. The hard part is making the onboarding disappear.

I launched Agent-Ready Docs Benchmark on Product Hunt without paying a hunter, influencers, or anyone else to push it. It ended with 51 votes and #19 overall.

This was not a paid launch. I did not pay a hunter. I did not pay influencers. I did not run ads. I shared it myself, messaged people directly, posted on LinkedIn and X, and dropped it into WhatsApp and Slack groups I am part of.

The short version is that Product Hunt is less of a neutral leaderboard than I thought. It is a one-day distribution event. The product matters, but so do your private network, the way you ask for support, and whether the platform gives you enough visibility to matter.

If you want the plain answer to the title, my answer was 51 votes and a #19 finish. That is what this launch produced without paying anyone. The rest of this post is about what seemed to drive that result and what I would do differently next time.

I wanted a trial run, not a perfect launch

I picked the benchmark because I wanted a narrow product surface for the experiment. I wanted to see how Product Hunt behaves when the product is easy to describe, the ask is simple, and the launch is mostly about learning.

The page got real attention, people actually used the product, and the launch was concrete enough to tell me something useful. It was a good reminder that narrow products are often better launch vehicles because they are easier for other people to understand and easier for you to evaluate honestly.

The launch was more private than public

The biggest lesson is that LinkedIn DMs were probably the main driver of votes. That is not a very glamorous answer, but I think it is the right one.

I cannot prove that cleanly with analytics because most of this lives inside direct messages, copied links, group chats, and other dark social channels. But when I compare the weak contribution from X with the responses I got from people I reached out to directly, the pattern is pretty obvious. LinkedIn DMs did more work than public posting. WhatsApp groups and Slack groups helped as well. X barely moved the needle. It likely contributed only 3 or 4 votes in total.

That was useful to learn because it changed how I think about launch-day effort. I would now treat direct outreach as the main channel, not as a supporting tactic around public posting.

This also changed my mental model of Product Hunt a bit. From the outside, it can look like a public internet event driven by homepage exposure and social momentum. In practice, at least for me, it behaved much more like a private trust event compressed into one day. A lot of the real movement happened in inboxes, chats, and small groups, not out in the open.

Being featured matters more than I thought

The other big lesson is that being featured matters more than I thought. This came up repeatedly in conversations with other founders. A lot of people said some version of the same thing: if you are not featured by Product Hunt, the launch gets much harder, and some founders will even cancel and relaunch rather than waste the day.

That sounded a little dramatic to me before this launch. It sounds much less dramatic now. The more I looked into it, the more obvious it became that visibility on Product Hunt is not evenly distributed.

Product Hunt is not just a neutral scoreboard for product quality. It is a distribution system with its own visibility rules. Once I accepted that, the outcome made a lot more sense. If I do this again, I will treat featuring as part of the launch plan itself because it can make or break the launch, not just as a nice bonus if it happens.

I had to separate launch-day signal from post-launch noise

One thing I am glad I checked carefully was what happened after the launch day. I went through the traffic and made sure to separate the launch-day traffic from the post-launch noise so I could see the carryover effects more clearly.

Every run on the benchmark creates a public report slug, so there is a natural second wave once people start sharing those links around. But those pages also attract crawlers and probes, which means not all carryover traffic should be read the same way.

What I would do differently next time

If I run another Product Hunt launch, I would change a few things.

First, I would build the launch around direct outreach from the beginning. I would prepare the contact list earlier, write shorter asks, and spend more time on the people who are actually likely to show up.

Second, I would treat featuring as a core part of the plan. I would not assume that a good product is enough to get featured. This thread has some insights about how PH decides who to feature, and I would use that to inform the launch strategy. I would also prepare for the possibility of not being featured and have a backup plan for how to get visibility in that case.

Some tricks other founders have mentioned include being active on Product Hunt before the launch, engaging with the community, and reaching out to the PH team directly to build relationships. Getting hunted by a well-known hunter can help too if you are willing to pay someone or know someone.

Finally, some people hire a dedicated “launch guy” just for launch day to focus on outreach, monitoring, and engagement. That might be worth considering if the stakes are high enough.

Final take

My simple conclusion is that Product Hunt was useful for exactly what I needed from it. It let me run a trial launch on a narrow product, learn how much direct outreach matters, and see how much of the outcome depends on visibility inside the platform.

The TLDR is this: LinkedIn DMs mattered more than public social. WhatsApp and Slack groups helped. X did very little. Being featured matters a lot. If I want a better result next time, I need to treat distribution and launch mechanics with the same seriousness as the product page itself. Product Hunt also discounts upvotes from newly created accounts, so if people want to support you, have them create their accounts a few weeks before launch.

I am also genuinely grateful for every one of those 51 votes. That number is still small enough that it feels personal. I can roughly tell who many of those people were, and I know they took a moment to support something I built. I do not take that lightly.

TLDR: We built a public docs benchmark that measures how readable your documentation is for AI agents. We had internal tools for this, but decided to make it transparent and vendor-neutral. The benchmark tests discovery, structure, task-readiness, and clean delivery—following patterns from the Agent-Friendly Documentation Spec.

AI agents are reading documentation more than humans now.

Every day, agents crawl docs sites to understand APIs, find integration examples, and figure out authentication flows. When they can’t parse your docs cleanly, they fail at tasks that should be straightforward. The problem isn’t model capability—it’s interface design.

We’ve been tracking this at Docsalot through internal agent traffic analysis. Most documentation failures happen at basic structural levels: no machine-readable entry points, HTML-only content, missing examples, unclear auth requirements.

We had closed internal benchmarks for analyzing this, but realized the broader ecosystem needed transparent measurement tools.

Most AI benchmarks have the same problem: vendors run them and also want to win them. This doesn’t make them dishonest, but it makes them hard to trust. If you define the scoring, pick the tests, and rank your own framework first, you’re writing a product page, not running a benchmark.

We faced this building Docsalot’s public docs benchmark. The obvious move: ship a flattering leaderboard, rank our stack high, call ourselves the best. The incentives are clear—benchmarks are free distribution.

That felt wrong.

Software has machine users now. We need measurements that reveal actual machine-readability, not which vendor wrote the test.

Narrow claims are useful claims

This isn’t a benchmark for “how good AI agents are” or “whether an agent can use your product end to end.”

It tests one thing: can an agent discover your docs, fetch them in machine-readable format, understand the structure, and find enough information to proceed without guessing?

Many “AI foundation model failures” are actually interface failures:

• no machine-readable entry point

• HTML-only docs with no clean markdown path

• navigation and cookie banners mixed into machine-facing content

• no clear prerequisites or auth constraints

• no examples

• no troubleshooting or recovery information

Humans skim and infer. Agents don’t.

What we actually score

The public benchmark uses four weighted buckets.

1. Discovery and delivery

This bucket checks whether the docs expose basic machine-readable entry points and retrievable text:

• does /llms.txt exist

• does /llms-full.txt exist

• do sampled documentation pages have valid .md versions

We sample from llms.txt links when available, otherwise fall back to /getting-started, /guide, /api, /reference.

2. Content structure

This bucket checks whether llms.txt is actually usable, not merely present:

• does it have an H1 title

• does it include a blockquote description

• does it use meaningful H2 sections

• do list items contain links

• do those links include descriptions

• is there an ## Optional section for lower-priority material

This follows patterns from The Agent-Friendly Documentation Spec (AFDocs) and its GitHub repository. The idea is simple: if a machine-readable index exists, it should help agents prioritize instead of forcing blind exploration.

3. Task readiness

This bucket checks whether the docs contain the kinds of details agents repeatedly need to complete real tasks:

• a clear opening description of what the product actually does

• prerequisites and constraints

• integration information

• troubleshooting or error-handling material

• concrete examples or code blocks

Pretty docs often fail here. Sites look polished but force agents to guess about auth, setup, limits, errors.

4. Access and recovery

This bucket checks whether the content is delivered in a form agents can actually use:

• do markdown pages return valid markdown rather than HTML or error pages

• are responses reasonably fast

• is the main content present in the initial HTML, or does it effectively require client-side JavaScript

• do pages support Accept: text/markdown

• is markdown output clean, or polluted with nav, footer, and consent cruft

Clean matters. Markdown with nav cruft is technically readable but practically noisy.

The methodology has to be inspectable

Benchmarks need transparency. We store breakdowns, individual checks, and methodology versions. External scores stay labeled as external.

Leaderboards collapse to integers, but the failure pattern matters more than the score. Did you lose points for missing llms.txt, dirty markdown, or no examples?

We disable domain-specific adjustments in benchmark mode. Our score widget has host-specific tweaks for user experience, but public benchmarks can’t have hidden exceptions.

Benchmark mode is stricter by design.

Why vendor neutrality matters

Neutrality isn’t about moral purity—it’s about diagnostic value. If your stack always wins, teams learn what you sell, not what works.

A credible benchmark needs to be willing to produce uncomfortable outputs:

• another docs stack can beat yours

• your own customers can outrank you

• open-source sites can outperform commercial platforms

• a site with plain design can beat a visually polished one because the machine-facing delivery is better

That is useful.

It creates a feedback loop around operability rather than brand preference.

What this benchmark still misses

This has limits. We don’t test full workflows, validate code, or exercise APIs. This measures docs operability, not software operability.

Still worth doing—docs are often the first interface agents hit. But we need separate benchmarks for CLI, API, auth, and recovery flows.

Seeing agent failures from missing structure makes the broader pattern obvious: this will happen in auth, setup, and recovery too.

Why this matters now

Software has machine users now. Buying, onboarding, support workflows start with agents reading docs.

If that first contact fails, adoption suffers before humans get involved.

We need benchmarks that are narrow, explicit, and neutral. Not because scores matter, but because visible failure modes give teams something to fix.

The argument for better AI agents is now familiar. Better models, better scaffolds, better tools, better data. What is less discussed is that agents do not meet the world directly. They meet software interfaces, and those interfaces are often much worse than we admit.

An agent can fail because the model is weak. It can also fail because the documentation is incomplete, the authentication flow is brittle, the CLI is inconsistent, the API surface is awkward, the system hides state that matters, or the product provides no clean way to verify success after side effects. Humans routinely work around these problems with patience and guesswork. Agents usually cannot. That difference matters because it means a large fraction of agent failure is not just about reasoning. It is about operability.

This is why an agent benchmark needs to exist. More precisely, we need a benchmark for how well agents can use real software under realistic conditions.

The Evaluation Gap

Most evaluation still focuses on one of three things. Benchmarks measure whether a model can solve a predefined task. Demos show that a happy path can be made to work. Product scorecards isolate one part of the stack and grade it in place. Each of these is useful, but none answers the full operational question.

There is already meaningful work on pieces of the problem. DocsAgent Score, Fern Agent Score, and the Agent-Friendly Documentation Spec all make the same point from different angles: if the documentation layer is malformed, unstable, or opaque to machines, the agent begins half-blind. On another axis, Sapient’s CLI leaderboard is important because it treats tool use as something that can be tested in live environments rather than described abstractly.

The problem is that software does not fail one layer at a time. Agents succeed or fail across a chain: discover the right interface, understand the docs, configure the environment, authenticate correctly, use the right surface, verify the result, and recover when something breaks. Measuring one link in isolation tells you something, but not enough. The real technical question is whether the system as a whole is operable by an agent.

Why Start With the Terminal

The recent Terminal-Bench paper is the clearest evidence I have seen that this problem is real and still undermeasured. Its importance is not that it is about shell commands. Its importance is that terminal work strips away a lot of benchmark theater and forces the agent to interact with a real environment. It has to inspect state, make decisions under uncertainty, respond to failures, and validate outcomes instead of merely narrating them.

Several lessons from that paper should shape any serious benchmark. Realistic long-horizon tasks are still difficult even for strong systems. Verification quality is central rather than optional. Many failures are operational: missing dependencies, bad paths, weak recovery, poor environment understanding. Token count and turn count are poor proxies for competence. An agent that wanders for 400 steps before stumbling into an answer is doing something categorically different from an agent that understands the environment, uses the right interface, and exits with a verified result.

That is why the terminal is a good starting layer. It exposes operational intelligence cleanly. But it should remain a starting layer. The larger question is not whether an agent can survive inside a shell. It is whether it can operate software across the interfaces modern systems actually expose.

What Agent Bench Should Measure

A useful agent benchmark should treat operability as layered.

Discovery. Can the agent find the right entry point, whether that is a doc page, a command, an endpoint, or a machine-facing tool surface?

Setup and authentication. Can it configure the environment correctly, understand the access model, and supply credentials in a way the system can actually use?

Interface use. Can it operate the available surface correctly, whether that surface is a CLI, an API, or an MCP-style interface? The question is not whether the interface exists. It is whether correct use is legible to a machine.

Verification. Can the agent determine that the action really succeeded? This is where many products appear usable in demos and then fall apart in practice.

Recovery. Can the agent detect partial failure, retry safely, and avoid hallucinating completion?

Once you frame the problem this way, the benchmark starts doing more than producing a score. It helps separate three things that are currently entangled in most discussions of agents: model capability, scaffold quality, and software quality. That separation is necessary if we want to know what actually needs to improve.

Why It Must Be Independent

The strongest reason to build this benchmark outside the frontier labs is not politics. It is measurement integrity.

If the dominant benchmark for software operability is controlled by the same organizations building the frontier models, the benchmark will be subjected to intense optimization pressure from the people with the most resources and the strongest incentives to win. That does not require anyone to cheat. It is enough that the benchmark becomes part of the development loop. Over time, a benchmark under that kind of pressure tends to become a coordination artifact for a handful of large actors rather than a durable public instrument.

Independence also matters because a lab-controlled benchmark will naturally reflect the assumptions of the labs closest to it: their harnesses, their preferred abstractions, their toolchains, their definition of what counts as agent progress. That narrows the scope of what gets measured. A genuinely independent benchmark can ask broader questions about interface design, verification burden, recovery quality, documentation structure, and software-side friction.

More importantly, independence is what makes the benchmark useful to the rest of the ecosystem. Product teams, infrastructure companies, open-source projects, and researchers need a measurement system they can treat as public infrastructure rather than as an extension of one model vendor’s go-to-market strategy. If the benchmark is going to tell uncomfortable truths about where software breaks agents, it has to be able to publish those truths without being subordinated to any one lab’s incentives.

There is also a deeper reason. The long-run value of this benchmark is not only that it ranks agents. It is that it creates a body of evidence about how software itself needs to change. If agents repeatedly fail on the same kinds of interfaces, auth patterns, setup flows, and verification gaps, that is not just model feedback. It is design feedback for the software layer of the AI era. That feedback loop is too important to leave entirely inside the labs.

Why This Matters

Software now has two users: the human operating the system and the machine acting on the human’s behalf. That shift changes the meaning of usability. We are no longer asking only whether a person can understand a product. We also need to ask whether the product exposes enough structure for an agent to discover it, configure it, act through it, verify results, and recover safely.

If we fail to measure that well, two things happen. We overstate model capability because demos hide the cost of brittle setup and weak recovery. And we deprive software teams of a serious feedback loop for building systems that agents can actually use.

A good benchmark would do the opposite. It would make failures legible, separate model limitations from interface limitations, and provide a shared technical standard for what agent-operable software looks like. That is why Agent Bench matters. Not as a marketing badge, and not as a narrow contest between frontier labs, but as public infrastructure for a world in which software increasingly has machine users.

References

• DocsAgent Score

• Fern Agent Score

• Agent-Friendly Documentation Spec (AFDocs)

• Sapient CLI Leaderboard / DevToolArena CLI benchmark

• Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces

I spent this week redesigning my landing page. The surprising part was not the typography, the footer, or the mobile nav. It was realizing that the page had to work in two completely different modes: persuasive HTML for humans, and boring markdown for agents.

That sounds obvious in hindsight. Of course it should work for both. The product I am building is about documentation that works for both humans and AI systems. If the landing page itself only works for humans, that is a weird contradiction.

But I think a lot of us still separate these things mentally.

We think of the landing page as the glossy marketing layer.
We think of llms.txt, markdown routes, and agent access as documentation infrastructure.

The more I worked on this, the less convinced I became that those are separate jobs.

If someone asks an agent “what does this product do?”, or “how much does it cost?”, or “is there a CLI?”, the answer is probably not coming from your docs reference first. It is often coming from your landing page, your pricing page, your tools page, your blog, and whatever else explains the product in plain language.

If those pages are hard to read mechanically, then a decent amount of your product positioning is trapped in human-only HTML.

The landing page is part of the interface now

There is a simple version of this argument:

If more product discovery is happening through AI answers, then the pages that explain the product are part of the API surface whether we like it or not.

Not API surface in the strict REST sense. I mean interface surface.

They answer questions like:

• what problem does this solve?

• who is it for?

• what do I do first?

• is there a free plan?

• does this have a CLI?

• does this support API docs?

For years, landing pages were allowed to be a little hand-wavy because a human reader could fill in the gaps. They could infer things from layout, screenshots, tone, and the general vibe of the page.

Agents are worse at that.

They are better at following structure.
They are better at clear copy.
They are better at plain text.
They are better when you give them a predictable place to look.

That means a lot of normal landing-page habits stop being enough.

The first problem was content, not code

Once you decide a page should have a machine-readable version, the fluff gets exposed instantly. A human reader might skim past inflated language. A markdown file makes every weak sentence much more obvious.

That ended up being useful. It forced me to write the page in a way that was clearer, more literal, and more defensible.

I think that is one of the more underrated side effects of building for agents: it is a good test for whether your copy makes sense at all.

I did not want a separate “AI site”

One tempting solution here is to build a totally different AI-facing microsite or dump a bunch of product facts into llms.txt and call it a day.

I did not want that.

The maintenance cost is bad, but the bigger problem is conceptual: if the human-facing page and the agent-facing page disagree, which one is real?

So I used a simpler rule:

The human page stays the canonical experience in the browser.
The machine-readable page should be a cleaner representation of the same reality.

That led to a structure like this:

• / stays the normal landing page

• /index.md becomes the canonical machine-readable landing page

• /llms.txt serves the same underlying content as /index.md

• /pricing.md, /tools.md, and /blog.md do the same for the main supporting routes

I also added a visible way for humans to switch to the markdown version, mostly because I dislike hidden infrastructure. If something is important enough to exist, it should usually be visible somewhere.

Why I kept both Accept: text/markdown and .md routes

In theory, content negotiation should be enough.

If a client sends:

Accept: text/markdown

then the same route can return markdown instead of HTML.

That part is nice because the URL does not change. A browser asks for HTML, an agent asks for markdown, everyone gets what they want.

But the web is never that clean.

Some agents send the right headers.
Some do not.
Some tools are inconsistent.
Some users just want a stable URL they can paste into a config file or inspect manually.

So I kept both:

1. explicit .md routes like /pricing.md

2. content negotiation on the corresponding human routes

Nothing especially clever there. The important part was being strict about explicit markdown media types instead of treating curl’s default */* as a signal.

That would have caused too many false positives.

llms.txt is useful, but it is not enough

I still think llms.txt matters. It is a good discovery mechanism.

But one thing I keep noticing is that people treat it as if it solves the whole problem.

It does not.

llms.txt helps an agent discover what exists.
It does not automatically make the content of the actual product pages cheap or easy to consume.

If someone pastes your pricing page into an agent, or the agent follows a link to the landing page, the thing that matters in that moment is not that llms.txt exists. The thing that matters is whether the page itself can be represented cleanly.

That is why I made /llms.txt and /index.md serve the same underlying landing content. I wanted discovery and representation to stay aligned instead of becoming two independent documents with their own drift.

The design work and the machine-readable work were the same project

I do not think of this as “I redesigned the landing page, and separately I added some AI files.”

It was one project.

The design pass forced the page to be simpler and more legible:

• clearer navbar

• less clutter in the hero

• cleaner CTA structure

• more consistent footer resources

• better mobile behavior

• more honest pricing copy

The machine-readable pass forced the underlying content and route structure to be more explicit:

• stable markdown URLs

• shared canonical content

• discovery headers

• CLI onboarding path that agents can actually follow

Those two things reinforced each other.

A simpler human page made the markdown representation better.
A better markdown representation made the human copy less sloppy.

That is probably the part I did not expect going in.

Why I think this matters beyond my site

I do not think every marketing site needs to become an AI-first artifact.

But I do think more teams are going to discover the same problem:

their knowledge-base may be in decent shape, while the pages that explain the product, pricing, setup, and workflow are still inaccessible or expensive for agents to consume.

That becomes a weird bottleneck.

The docs say one thing.
The landing page says another.
The pricing page is trapped in a JavaScript-heavy layout.
The CLI exists, but the onboarding path is only obvious to a human clicking around.

Agents can work around a lot of this. That does not mean they should have to.

My guess is that the next normal version of public product pages will have two equally intentional representations:

• the designed page for humans

• the plain representation for machines

Not because of ideology. Just because the distribution surface has changed.

What I would do first if I were retrofitting another site

If I had to do this again on a different site, I would do it in this order:

1. fix the copy first

2. create a canonical markdown version of the landing page

3. add llms.txt

4. add markdown routes for pricing and other high-intent pages

5. add explicit discovery headers

6. only then bother with fancier switching and UI affordances

The order matters because clean content beats clever plumbing.

If the page is still vague, markdown just exposes vague text faster.

The useful takeaway

The practical lesson for me was pretty small:

Do not treat your landing page as separate from your agent surface.

If the page explains what the product is, how it works, how much it costs, and how to get started, then that page is already part of the input material for agents.

You can either make that representation explicit, or let every tool scrape and guess.

I would rather make it explicit.

That ended up being one of the more satisfying weeks I have had in a while, partly because the result is visible and partly because it removed a contradiction that had been bothering me.

TLDR: The docs market looks crowded if you count the number of vendors. It looks a lot less crowded if you look at the documentation most teams actually ship. That’s the short version of why I think DocsAlot should exist. Its customer driven, not investor driven. Most existing platforms are bloated, and trying to be everything to everyone.

I am not arguing that competition does not exist. It obviously does. I am saying there is plenty of room at the bottom

GitBook is established. Scalar has a strong API-first position. Docusaurus, Fumadocs, starlight are solid open-source options. There are plenty of smaller tools too.

But “there are competitors” is not the same thing as “the market is closed.”

One of the cleaner explanations of this came from Max Rozen, who wrote about building OnlineOrNot in a category with roughly 200 listed alternatives. His point was not that competition is fake. It was that markets are messier and product fit is uneven. Buyers are rarely choosing from a tidy spreadsheet of ten well-understood options. A lot of them are using whatever they already know, whatever a friend mentioned, or whatever happened to show up first.

That framing matches what I see in documentation.

The docs market is not one market

People talk about “documentation platforms” as if they all solve the same problem. They do not.

From where I sit, the category is splitting into at least three different buckets.

1. AI-native and automation-first products

This bucket is optimizing for structured specs, generated SDKs, machine-readable outputs, agent access, and automation pipelines.

Mintlify is a clear example of this. Even the product framing has moved well beyond “nice docs site.” The company now describes itself as an intelligent knowledge platform, with features around AI answers.

The direction of travel is obvious: not just hosted docs, but infrastructure for knowledge consumption. A common pattern when you have raised a lot of money is to expand the vision and the product at the same time. That is what I see happening here. If they go along this direction, expect customer support bots like Pylon, as that’s a bigger market.

Fern is in a similar family, but from the API side. The core pitch is spec-first API infrastructure: generate SDKs, generate docs, keep them aligned, and increasingly support agent-readable surfaces like llms.txt and MCP. It is a serious product for teams that want their API surface treated like a system, not just a website. Fern recently was acquired by Postman, which is another sign that this side of the market is converging with broader API platform infrastructure rather than staying a narrow docs category forever.

These are not bad products. They are doing the rational thing. But once a company starts expanding in that direction, the product changes.

2. Human-native workflow platforms

This bucket is stronger when the problem is editorial workflow, internal collaboration, permissions, review loops, and narrative authoring across teams.

GitBook is the obvious example. It has a strong editor, collaborative workflows, permissions, publishing controls, AI answers, Git sync, and an MCP server. That makes sense if your real problem is not “render my API reference beautifully,” but “help multiple humans across support, engineering, product, and solutions keep a large knowledge surface coherent.”

That is a real need. It is just a different one.

3. Open-source frameworks

Then there is the third category: tools like Docusaurus and Fumadocs.

These are not really “buying a docs platform” in the SaaS sense. They are frameworks. They give you a strong starting point, but you still assemble and run the system yourself. You choose hosting, deployment, content workflow, permissions, previews, analytics, and whatever agent-facing pieces you want to bolt on.

In summary, that distinction matters because people often look at a list that includes GitBook, Docusaurus, and Fumadocs and conclude that the category is saturated. I think that is the wrong read. What I see instead is fragmentation. These products are solving adjacent jobs, not identical ones.

Why I think documentation demand goes up from here

The bigger reason I am comfortable building in this market is that I think the need for documentation is increasing.

1. APIs are moving closer to the default

I do not mean every product will expose a perfect public REST API next quarter. The transport does not matter that much. Some products will expose APIs. Some will expose agent actions. Some will expose MCP-compatible tooling. Some will wrap existing product surfaces in a machine-friendly layer later.

The underlying pressure is the same: software is becoming more composable, and products that are easy to integrate into automated workflows have a large advantage.

That changes the role of docs. Documentation used to be downstream from the product. Build the thing, then explain it. But increasingly, documentation is part of the interface.

If a user is onboarding through a coding agent, the docs are no longer just a support artifact for a human engineer skimming examples. They are part of the material that lets the agent understand what the product is, what operations are available, what the constraints are, and how to combine actions safely.

2. More people are going to act like developers

I also think the total number of people producing software behavior is going up because AI is making software construction more accessible.

That does not mean everyone turns into a strong software engineer. It means more people can express intent in software-adjacent ways: shipping workflows, wiring tools together, automating ops, building internal utilities, and standing up small products without traditional teams.

Whether you call them developers or not is secondary. The important part is that they still need interfaces they can understand and trust.

More builders means more APIs, more integration surfaces, and more documentation demand.

This is one of the places where I think people underestimate the second-order effect of coding agents. Even if code generation gets easier, the surrounding coordination problem gets bigger. More software gets made. More endpoints exist. More tools become partly programmable. More documentation has to exist to explain all of that to humans and to machines.

3. Docs now need human and machine affordances

The docs page is no longer the whole artifact.

Now you also need the machine-readable and agent-discoverable layer around it: llms.txt, MCP endpoints, skill files, structured reference, and other small artifacts that make a product legible in AI-native workflows.

The good news is that these are not especially hard to produce once you have the right source of truth.

The bad news is that if you do not produce them, your product becomes less visible and less usable in the workflows that are growing fastest.

That is another reason I do not think this category collapses into a few incumbents. The requirements are expanding.

Why strong competitors do not close the market for a smaller product

The strongest argument against building DocsAlot is obvious: why enter a market with credible incumbents?

My answer is that incumbents do not just create competition. They also create openings.

As companies raise more money, move upmarket, or get pulled into adjacent categories, they usually get broader. That is rational. Customers ask for more workflow, more enterprise controls, more AI, more governance, more analytics, more collaboration, more import paths, and more content types.

That is how a clean product turns into a platform.

Sometimes that broadening creates a better product. Often it creates a heavier one. We have all seen what happens when a sharp tool keeps absorbing new obligations.

I am not using “enshittification” here as a slogan. I mean something simpler: products accumulate obligations. They stop being allowed to stay narrow. They have to serve more segments, more stakeholders, and more edge cases than they originally did.

That broadening is one of the main reasons small products can still win in seemingly crowded categories.

From the outside, a company like Fern looks like a docs competitor. And it is. But it is also increasingly an AI knowledge product. GitBook is a docs competitor, but it is also a workflow and knowledge collaboration product and a customer support bot. Fern is a docs competitor, but it is also an SDK generation product. Docusaurus and Fumadocs are alternatives, but they are really framework choices.

That leaves room for a narrower thesis.

The thesis for DocsAlot

The DocsAlot thesis is not “we will beat everyone by having every feature.” That is the fastest way to become mediocre.

The thesis is smaller:

1. Make good-looking public docs.

2. Keep them in sync as soon as people commit doc changes.

3. Make the docs legible to agents as well as humans.

That sounds almost too small, but I think that is the point.

There is a lot of demand for a product that does one thing well: take docs-as-code seriously, publish something attractive, keep it updated without ceremony, and generate the adjacent machine-facing assets that now matter.

Not an internal wiki. Not an all-purpose knowledge platform. Not an everything suite for docs, support, product education, and AI governance.

Just a sharp, opinionated product for teams that want their docs to look good, stay current, and be easy for both people and agents to consume.

That is especially interesting to me because the failure mode in docs is often not “we picked the wrong platform.” It is “we stopped maintaining the docs because the workflow was too annoying.” Or “the docs were technically there, but the public experience was bad.” Or “the product worked for humans but had no machine-readable discovery layer.” Or “the framework was flexible, but now we are maintaining a docs stack instead of shipping the product.”

A smaller product can take those failure modes more seriously because it is not trying to solve seven adjacent problems at the same time.

Competition matters less than clarity

The part of Max Rozen’s argument that stuck with me is that the existence of many competitors does not mean the buyer is seeing all of them clearly. Often they are seeing almost none of them clearly.

That feels true in docs. Most teams are not running a perfect market scan of every documentation platform and every open-source option. They are taking recommendations from friends, copying the last tool they used, defaulting to whatever their VP of Engineering already knows, or hacking together the path of least resistance.

That is why I think lack of awareness matters more than competitor count.

If the product is clear, the setup is simple, the docs look good, the sync story is strong, and the agent-facing artifacts are handled automatically, there is still plenty of room to matter.

You do not need to “win the market” in the abstract. You need to become the obvious answer for one kind of team.

For DocsAlot, the bet is that there will be more of those teams over time, not fewer:

• teams shipping APIs faster because agents make software construction cheaper

• teams that want docs-as-code, but not a giant internal platform

• teams that care about aesthetics and readability

• teams that need docs to be understandable by humans and machines

• teams that do not want to maintain a custom docs stack forever

If that bet is right, the crowdedness of the category matters less than the direction of the category.

My read is that the direction is favorable.

A final note on “crowded”

Crowded markets are often good markets.

They mean the pain is real.

The more important question is whether the pain is solved cleanly for the specific segment you care about. In docs, I do not think it is. The category already contains strong products, but they are increasingly optimized for different ends: platform breadth, enterprise workflow, API infrastructure, or framework flexibility.

I think there is still room for a smaller, more opinionated product that treats documentation as a first-class interface layer, keeps it synced to the codebase, and makes the result legible to both people and agents.

Maybe the market proves me wrong. But “there are already competitors” is not a good enough reason not to build.

If anything, in documentation right now, it is a reason to be more precise about what kind of product you are actually building.

References

• Richard Feynman,

  There’s Plenty of Room at the Bottom: An Invitation to Enter a New Field of Physics

• Max Rozen on operating in a crowded market:

  On four years of running a SaaS in a competitive market

• Docusaurus and Fumadocs as frameworks rather than hosted docs platforms: Docusaurus, Deployment, Fumadocs, Docs

• https://docsalot.dev

TLDR: A good CLI solves part of the problem. It does not solve cross-OS distribution, desktop client compatibility, or non-technical adoption. For Docsalot, MCP matters because it gives us one protocol surface instead of a growing pile of binaries.



A good CLI is still worth building. We built one for Docsalot. But a CLI does not remove the need for MCP. In some ways it makes the remaining problem more obvious.

The reason is simple: once you ship a CLI, you own distribution.

Not just the npm package or the README. The actual operational surface. macOS. Linux. Windows. Node versions. PATH issues. Shell behavior. Desktop clients that do not want a shell at all. Users who are not comfortable in a terminal. Every one of those becomes part of the product whether you wanted it or not.

That is the part people skip when they say “why not just expose a CLI?”

A CLI is one interface. MCP is a protocol.

That difference matters a lot.

What the CLI Solves

A CLI is great when the user is already technical and already in a shell.

For Docsalot, our CLI gave us a clean workflow for:

• authenticating with API tokens

• listing documentations

• pulling docs locally

• pushing docs back as a version

• publishing a version

• previewing docs locally

That is a real product surface. It is useful. It also maps well to agents that can run terminal commands.

If the world stopped there, we could have just kept improving the CLI.

But it does not stop there.

What the CLI Does Not Solve

A CLI does not magically become universal just because it exists.

To make it broadly usable, you still have to answer questions like:

• How do we distribute this cleanly across macOS, Linux, and Windows?

• What runtime assumptions are we making?

• What happens when the user’s shell environment is weird?

• What happens when a desktop AI client does not want to manage a local binary?

• What happens when the person updating docs is not technical enough to debug PATH, npx, or Node versions?

We ran into exactly this kind of friction while testing the MCP path through desktop clients.

Even when the Docsalot server was fine, the local environment could still fail in annoying ways:

• an old npx being picked from the wrong Node install

• a client resolving the wrong node binary from PATH

• a remote bridge working on one machine and failing on another

None of those are really “documentation problems.” They are packaging and runtime problems.

That is the hidden tax of a CLI-first distribution model.

The Distribution Problem Is Worse Than It Looks

When people say “just ship a CLI,” they usually mean “technical users can figure it out.”

That is often true. It is also a weak standard if you want broad adoption.

A CLI means you are effectively shipping multiple operational experiences:

• one for macOS users

• one for Linux users

• one for Windows users

• one for whoever has the wrong language/runtime version installed

• one for whoever is trying to call your tool through an AI desktop app instead of a shell

Even if the commands are logically the same, the support burden is not the same.

You do not just have one product anymore. You have the combinatorics of product × operating system × runtime × client behavior.

That is manageable for a small technical audience.
It is not a great default if your goal is: “connect once and let any compatible client use the workflow.”

What MCP Changes

MCP gives you a stable protocol surface instead of asking every user to adopt your local runtime assumptions.

That is the key point.

With a remote MCP server, the client only needs to know how to speak MCP. The server owns the implementation details. The auth model is explicit. The tool schemas are explicit. The request/response format is explicit.

For our Docsalot docs-management flow, that means we can expose:

• list_documentations

• pull_documentation

• push_documentation

• publish_documentation

as one authenticated surface at /api/cli/v1/mcp.

Now the integration problem shifts from:

“Can this user install and run our binary correctly on this machine?”

to:

“Can this client talk MCP?”

That is a much better question.

It is narrower. It is more standard. It ages better.

Why This Matters Specifically for Docsalot

Docsalot is not just serving docs to engineers in terminals.

We also care about:

• coding agents operating documentation directly

• desktop MCP clients

• less technical users making documentation updates without learning a CLI

• workflows that should behave the same way across different environments

If we stayed CLI-only, we would keep paying the binary tax forever.

That means:

• more packaging work

• more support work

• more environment debugging

• more platform-specific docs

• more chances for “works on my machine” to become part of the user experience

MCP does not make all integration problems disappear. It does remove one big class of them.

Instead of shipping the same docs-management workflow as multiple binaries and hoping each client environment behaves, we can expose one protocol surface and let MCP-compatible clients connect to it.

That matters even more when the user is not technical.

If a product manager, support lead, or founder can connect through a desktop app and update docs without touching a shell, that is not a nice-to-have. That is a real expansion of who can use the system.

This Is Not an Argument Against CLIs

CLIs are still useful.

In our case, the CLI still matters for:

• local preview

• terminal-native workflows

• direct automation

• users who want explicit command-level control

The point is not “MCP replaces the CLI.”

The point is that a CLI and an MCP server solve different distribution problems.

The CLI is for users who want to run your workflow locally.
MCP is for users and clients that want a stable protocol surface without inheriting your packaging story.

Those are not the same thing.

The More Honest Framing

I think the more honest way to talk about MCP is this:

MCP matters when you want one interface to work across many clients without shipping your implementation details to every user environment.

That is the win.

For Docsalot, that means we can keep the CLI for local power users and still expose docs management through a protocol that works across MCP-native clients.

That gives us:

• less cross-OS binary overhead

• less environment-specific breakage

• better compatibility with desktop clients

• a more accessible path for non-technical users

Or, more bluntly:

Connect once, communicate forever is a better distribution model than shipping the same docs workflow as a growing pile of binaries.

You can get a custom email address that forwards to your Gmail inbox for free using Cloudflare’s Email Routing feature. You can even send from that custom address using Gmail’s “Send mail as” feature. The whole thing costs you nothing except the domain itself.

Here is the full walkthrough.

What You Need

Three things. You probably already have two of them.

1. A domain name: $10–15/year from Namecheap, Porkbun, or any registrar. Budget options like .xyz, .site, or .online run $2–5/year.

2. A Gmail account: free.

3. A Cloudflare account: free.

Step 1: Get a Domain

If you don’t have one already, go buy a domain. Namecheap, Porkbun, whatever. Pick something short, memorable, and on-brand for you.

If you already own a domain, skip ahead.

Step 2: Add Your Domain to Cloudflare

1. Sign up at cloudflare.com. The free plan is all you need.

2. Click “Add a site” and type in your domain.

3. Cloudflare will scan your existing DNS records automatically.

4. It will give you two nameservers. Copy them.

5. Go back to your domain registrar (Namecheap, Porkbun, wherever you bought the domain) and replace the default nameservers with the two Cloudflare gave you.

6. Wait about 5–10 minutes for DNS propagation.

That’s it. Your domain is now on Cloudflare. Everything else happens inside their dashboard.

Step 3: Enable Email Routing

This is where the magic happens.

1. In your Cloudflare dashboard, navigate to Email → Email Routing.

2. Click “Get Started” to enable the feature.

3. Enter your Gmail address as the destination.

4. Cloudflare will send a confirmation email to that Gmail address.

5. Open Gmail, find the email, click the verification link.

Done. Cloudflare now knows where to forward your mail.

Step 4: Create Your Custom Email Addresses

Now you get to pick whatever addresses you want.

1. In the Email Routing section, click “Create address.”

2. Type the local part you want — hello@, contact@, hi@, support@, sales@, whatever.

3. Select your Gmail as the destination.

4. Click Save.

Repeat this for as many addresses as you want. They are all free. Unlimited. Each one can point to the same Gmail or to different inboxes if you have multiple Google accounts.

At this point, emails sent to hello@yourdomain.com land in your regular Gmail inbox. That alone is useful. But we can do better.

Step 5: Send FROM Your Custom Email

This is the part that makes it feel real. Right now you can receive emails at your custom address, but when you reply, Gmail sends from your @gmail.com address. That’s ugly. Let’s fix it.

1. Open Gmail → Settings → See all settings.

2. Go to the “Accounts and Import” tab.

3. Under “Send mail as”, click “Add another email address.”

4. Enter your name and your custom email (e.g., hello@yourdomain.com).

5. On the next screen, Gmail asks for SMTP server details. This is the part people mess up.

Here is what to enter:

Field Value SMTP Server smtp.gmail.com Port 587 Username Your full Gmail address (e.g., you@gmail.com) Password A Google App Password (see below)

Important: Gmail will pre-populate the SMTP server field with something from Cloudflare’s MX records. Delete that. Replace it with smtp.gmail.com. If you skip this, it will not work.

Getting a Google App Password

You need this because Gmail won’t let you use your regular password for SMTP.

1. Go to Google Account → Security

2. Make sure 2-Step Verification is enabled. (If not, enable it first.)

3. Search for or navigate to App passwords.

4. Generate a new app password for “Mail.”

5. Copy the 16-character password Google gives you.

6. Paste it into the Gmail SMTP setup from above.

Finishing Up

1. Click “Add Account.”

2. Gmail sends a verification email to your custom address.

3. Cloudflare forwards it right back to your Gmail inbox. (See? The routing is already working.)

4. Enter the confirmation code or click the link.

You can now compose emails in Gmail and choose your custom address in the “From” dropdown. Replies to emails received at your custom address will default to sending from that address too.

Step 6: Verify Your DNS Records

Cloudflare automatically sets up SPF, DKIM, and DMARC records when you enable email routing. You don’t need to touch anything manually. But if you want to double-check:

1. Go to Cloudflare → DNS → Records.

2. You should see MX records pointing to Cloudflare’s mail servers.

3. You should see TXT records for SPF and DKIM already in place.

If something looks wrong, try disabling and re-enabling email routing. That usually resets everything correctly.

A Note on DKIM and Deliverability

Here is the one honest caveat. Unlike Google Workspace, regular Gmail does not sign outgoing emails with your custom domain’s DKIM key. This means some recipients, especially stricter corporate mail servers, might flag your messages or land them in spam.

In practice, I have not had issues. But if you start noticing deliverability problems at scale, that is the point where paying for Google Workspace actually makes sense.

What You End Up With

• Emails sent to hello@yourdomain.com arrive in your normal Gmail inbox.

• You can reply from that custom address directly in Gmail.

• You look professional.

• You pay $0/month for email. Just the annual domain cost.

• No separate storage limits. It is all using your free Gmail storage (15 GB).

That is a professional email setup for roughly $10/year instead of $72+/year with Google Workspace.

Limitations

This setup is not a full replacement for Google Workspace. Here is where it falls short:

• Cloudflare only forwards. It does not store emails or give you a separate mailbox. If your Gmail goes down, you have no backup.

• Outgoing emails might hit spam initially until SPF reputation builds up for your domain.

• Gmail’s sending limit is 500 emails/day from custom addresses. Fine for most people. Not fine if you are doing cold outreach at volume.

• No DKIM signing on your custom domain. Covered above — but worth repeating.

That’s It

This is not sponsored by Cloudflare. I just happened to know this method and it felt like the kind of thing worth writing up. If you know other free or cheap hacks like this, I’d genuinely like to hear about them.

In January/26, Arena, the platform formerly known as LMArena, formerly known as LMSYS Chatbot Arena, announced a $150 million Series A led by Felicis and UC Investments, with participation from Andreessen Horowitz, Kleiner Perkins, and Lightspeed. That is on top of the $100 million seed round they closed less than a year earlier. A quarter billion dollars for a platform whose core mechanic is: show two outputs, hide the labels, ask a stranger which one is better.

The Core Claim

Everyone already agrees that data matters. That is not the argument.

The argument is this: the best product for collecting useful model feedback is a blind comparison interface. Not a benchmark suite. Not a multiple-choice exam. A head-to-head fight in front of a human judge who does not know which model produced which answer.

Arena proved this for text. Over 50 million votes from real users, across 400+ models, spanning text, vision, code, image, video, and search. The platform started as a PhD research experiment at UC Berkeley. It is now, by funding and by influence, one of the most important pieces of AI infrastructure in the world.

Design Arena, built by Arcada Labs, is proving it for interface and visual generation. 2.2 million users picking winners across website design, game dev, 3D modeling, data visualization, logo, video, and more, all rated with the same Elo-based Bradley-Terry system. When Claude Opus 4.6 sits at the top of that leaderboard, it is not because Anthropic said so. It is because strangers on the internet, who did not know which model made which output, clicked on it more often.

The mechanism is the same every time:

Two answers appear.
The user picks one.
The system updates rankings.
The platform learns what people actually prefer.

That loop is the point.

Why This Product Pattern Wins

Three things, and they compound.

First, brand bias disappears. If users do not know the model name, they judge output quality, not reputation. This matters more than it sounds. There is a well-documented tendency in AI evaluation for people to rate GPT-4 outputs higher when they know it is GPT-4. Remove the label and the rankings shift. Arena’s entire credibility rests on this insight.

Second, binary decisions scale. A/B choices are fast, clear, and cognitively cheap. You do not need an expert to say “this website looks better.” You need a lot of people saying it, quickly, and a good statistical model to aggregate. That is exactly what Elo provides.

Third, evaluation becomes continuous. Instead of waiting for a quarterly benchmark release (which may not even reflect how people actually use models), arena platforms measure quality in real time. A model that ships an update on Tuesday has new signal on Wednesday.

This is why teams trust arena-style rankings. They are not perfect. But they track real preference in real time, which turns out to be far more useful than a static leaderboard that measures performance on a fixed test set.

The Evidence: Follow the Money

Arena’s $250 million in total funding is the most visible signal. But it is not the only one.

The entire training-data and evaluation stack is converging toward the same thesis. Scale AI, the incumbent in post-training data and RLHF, is evolving from raw labeling into workflow-level RL environments. Datacurve runs a “bounty hunter” marketplace where skilled engineers tackle complex code and data tasks for frontier model training. Mercor connects AI labs with domain experts for RLHF. Surge AI focuses on expert labeling for reasoning and long-form tasks. Turing provides large expert workforces for fine-tuning and evals. Invisible turns complex, multi-step human workflows into verifiable work traces that function as de facto training environments.

But here is the key distinction, and it is why this post is not about the training-data ecosystem. Those companies improve models by generating better data. The arena pattern improves models by generating better signal. A blind head-to-head vote does not teach a model what to say. It tells the lab which model already says it better — and by how much. That is a fundamentally different feedback mechanism: not data supply, but preference measurement. The data companies feed the training loop. The arenas close it.

The smart money is flowing into both. But the arenas are the part that scales with users rather than annotators, which is why a voting platform can raise a quarter billion dollars.

Why It Matters for Model Companies

Model labs need a reliable way to answer one practical question: did the last update make users happier, or not?

Traditional benchmarks answer a different question: did the model get better at tasks we defined in advance? The gap between those two questions is where most evaluation failure lives. A model can improve on MMLU, HumanEval, and every public benchmark while regressing on the things users actually care about: tone, helpfulness, creativity, visual coherence, code that runs on the first try.

Blind comparison products close that gap. They measure what people prefer, not what a test suite rewards. That is why every major lab now watches Arena rankings obsessively. It is why OpenAI, Google, Anthropic, and a dozen others submit models under codenames before public release. The arena is their pre-launch focus group, except the sample size is in the millions and the methodology is more rigorous than any internal eval.

But what about the objections

“Arena rankings are gameable.” True in theory. Model providers can optimize specifically for arena-style prompts. But in practice, the sheer volume and diversity of users makes this harder than gaming a fixed benchmark. 50 million votes from strangers is a harder target to overfit than 1,000 curated test cases.

“Human preference is noisy and inconsistent.” Also true. But Elo systems are designed precisely for this. They extract a stable signal from many noisy pairwise comparisons. That is literally what the algorithm was built to do, originally for chess, now for language models.

“Blind comparison only works for simple outputs.” This is the strongest objection. For complex, multi-step agent tasks, a simple A/B vote may not capture quality. That is exactly where players like Halluminate are building: richer evaluation environments where the “judgment” is more structured than a single click. The core pattern (human feedback, captured systematically, turned into a ranking signal) still holds. The interface just needs more surface area.

Elo Driven Development

Elo systems are useful here because they do something no static benchmark can: they turn many small pairwise decisions into a ranking that moves with user preference, continuously.

The development loop for a frontier model increasingly looks like this: train a model, ship it to an arena, watch the Elo rating, identify where it loses, retrain on the gaps, ship again, watch the Elo move. The arena is not just the evaluation layer. It is becoming the development feedback loop itself.

This is a structural shift.

What Happens if Everyone Behaves Rationally

Start with the big labs. If you are OpenAI, Google, or Anthropic, you now have an external scoreboard that your customers, your investors, and your recruits all watch. You cannot ignore it. The rational move is to treat arena rankings as a first-class product metric, right alongside internal evals and revenue. That means submitting every model update to Arena and Design Arena before launch, building internal tooling that correlates Elo movement with architecture changes, and staffing teams whose job is to close gaps that arena data reveals. Some labs are already doing this. Within a year, all of them will be.

The second-order move is more interesting. If arena rankings drive reputation, and reputation drives enterprise contracts, then labs have an incentive to invest directly in arena infrastructure. Not to manipulate rankings, but to ensure the arenas they depend on remain credible and well-funded. Expect to see labs become strategic partners, data contributors, or even minority investors in arena platforms. Arena’s Series A investor list (a16z, Kleiner Perkins, Lightspeed) already reads like a who’s-who of AI lab backers. That is not a coincidence.

Now consider VCs. The arena pattern has a clear power-law dynamic: the platform with the most users generates the most votes, which produces the most trusted rankings, which attracts more models, which attracts more users. That flywheel favors early movers and makes the category winner-take-most per modality. If you are a VC, the rational play is to identify the emerging arena for each new modality (code, design, video, audio, agentic workflows) and fund the front-runner before the flywheel becomes self-sustaining. Arena and Design Arena are already there for text and visual generation. The next arenas to watch are for agent evaluation, audio, and domain-specific verticals like legal, medical, and finance.

For startup founders, the calculus is different. Building a general-purpose arena to compete with Arena head-on is probably a losing bet. But building a vertical arena, one that serves a specific modality, domain, or user base, is wide open. Design Arena proved this: you do not need to be Arena to matter. You need a focused judge pool, a clear modality, and enough model coverage to make the rankings useful. The founders who understand this will build arenas for niches that the general platforms cannot serve well. Think: an arena for medical summarization judged by physicians. An arena for contract analysis judged by lawyers. An arena for code review judged by senior engineers. Each is a small market on its own, but the ranking data they produce is extraordinarily valuable to any lab building models for those verticals.

The final actor is the training-data ecosystem: the Scale AIs and Datacurves of the world. If arena rankings become the scoreboard that matters, then the value of their work rises in direct proportion. Better training data leads to higher Elo. Every point of Elo translates into deals, press, and recruiting advantage for the lab. That makes the data companies direct beneficiaries of the arena economy, and it means they will increasingly price and position their services around Elo improvement as a deliverable, not just data volume.

Put it all together and you get a new equilibrium: labs compete on arenas, VCs fund the arenas and the data infrastructure around them, founders build vertical arenas for underserved modalities, and data companies sell Elo points instead of labeled rows. The arena becomes the central coordination mechanism for the entire AI improvement stack.

A quarter billion dollars for a voting interface. The market is telling you that the next breakthrough in AI may come from building a better arena.

I read one book a month (here’s the list), and Anything You Want by Derek Sivers was my February pick. I don’t usually write essays about the books I read, but this one was so relevant to where I am in my journey that I had to spend some time distilling my notes.

Core Idea: Help First, Money Second

One theme repeats throughout the book: don’t do things just for money.

Money matters because it keeps the work sustainable, but it should not be the point of the work. The point is helping people solve real problems.

That framing sounds simple, but it changes everything, and it’s not just indie founder wisdom. PG argues the same thing for funded startups: the best early-stage tactic is an almost pathological focus on making users happy (https://paulgraham.com/ds.html).

It changes:

• what products you build

• who you serve

• what you say no to

• how you define success

All Notes

1) Start before you feel ready

Sivers makes the case that plans are mostly guesses until customers show up. You only discover what people want by shipping something and listening.

So instead of thinking big, start with a tiny problem and solve it well.

Paul Graham makes the same point, Stripe’s founders didn’t wait for signups—they walked up to people and installed it on their laptops on the spot.

2) Execution beats ideas

Ideas are a multiplier of execution. If execution is zero, ideas are zero.

This is one of the most useful filters for founders: less theorizing, more shipping, more iteration.

PG’s version of this: obsessing over a big coordinated launch is a trap—steady, compounding effort is what actually works.

3) Many small customers create freedom

A business dependent on one giant customer is fragile.

A business with many small customers is resilient. No single customer controls your roadmap, and you can optimize for the majority you truly want to serve.

4) Exclusion is strategy

Trying to be everything to everyone usually means being meaningful to no one.

Be explicit about who your product is for, and who it is not for.

PG calls this the “contained fire” strategy (https://paulgraham.com/ds.html), Facebook launched as Harvard-only, and building course lists school by school is what made students feel the site was theirs.

5) Build a business that runs without you

A strong line in the book is making yourself unnecessary in day-to-day operations.

If everything depends on you, you own a stressful job. If the system runs without you, you own a business.

6) “Hell yeah or no”

If you’re not excited about an opportunity, decline it. Saying yes to everything dilutes your focus. Raising your bar for a yes creates space for the things that actually matter.

7) If it’s not a hit, switch

Success comes from consistently improving and inventing, not from stubbornly promoting what isn’t working. Sivers compares it to music: when you have a hit song, it promotes itself. When you don’t, no amount of pushing will save it.

Persistence matters, but apply it to iterating your way to a hit, not to repeating a failing approach.

8) Little things make all the difference

CD Baby answered the phone within two rings. They customized the “from” name on emails to say “CD Baby loves [customer’s first name].”

You don’t need a huge budget for this. You just need to care enough to add a small moment of delight where nobody expects one.

9) Formalities are fear

Stay away from corporate formalities as much as you can. No amount of privacy policy or terms of service is going to save you. There are shops like Jim’s Shiva Shack earning real money without any of that.

People will scare you into thinking horrible things will happen if you don’t do this or that. Most of the time, they won’t.

10) Your first idea is just one of many options

No business goes as planned. Sivers suggests making ten different plans for the same idea i.e. different price points, different markets, different models.

Realizing the initial choice you made was just one of many brings a kind of weathered wisdom. The same applies to life: there’s no single correct path, just the one you’re currently exploring.

11) Start by sharing whatever you’ve got

Don’t wait until you have something polished. Start by sharing whatever you have, charge something for the effort so the thing can continue, but the starting point is generosity, not perfection.

My Takeaways

I’m walking away with a few practical rules:

• Ask customers directly: “How can I help?”. That alone simplies the roadmap more than you think. Customers are busy, they don’t know how anyone can help them. If you simply ask, they will think about it and tell you.

• Start small and do unscalable things early. (PG’s entire essay on doing things that don’t scale is the VC-backed version of this same instinct.) Derek had half the book devoted to this point.

• Charge enough to sustain the work. This points relates to infinite games by James Carse. If you want to play an infinite game, you need to make sure the game can continue. That means charging something for your work, even if it’s not much. (https://www.amazon.ca/Finite-Infinite-Games-James-Carse/dp/1476731713)

• Find your own measure of success. Different people have different definitions. If you don’t have one, you will be living up to other peoples definition of success.

Final Thought

The book’s biggest shift for me is this: if you keep helping real people and keep improving what you ship, direction emerges.

That’s enough to begin.

Inference demand is exploding. Inference startups are still getting acquired or shutting down. Both statements are true at the same time.

TLDR: most independent inference platforms don’t fail because demand is weak; they fail because they mistake revenue momentum for economic durability.

The Pattern So far

• BentoML — acquired

• Ploomber — shut down

• Modelbit — shut down

• Replicate — acquired

• Lepton AI — acquired

• Brev – acquired

• Predibase – acquired

• Openpipe – acquired

• OctoAI – acquired (raised ~$130M+ before acquisition)

Whether every item remains exactly current by the time you read this matters less than the directional truth: standalone inference providers keep getting pushed toward consolidation.

Why? Because this is a balance-sheet business pretending to be a pure software business.

A Simple Framework: Three Clocks You Don’t Control

Most founders model one clock (revenue growth). Inference startups live under three:

1. Cost clock — GPU pricing, availability, and model mix can reprice your COGS (cost of goods sold) quickly.

2. Demand clock — customer traffic is lumpy, seasonal, and frequently non-linear.

3. Reliability clock — enterprise expectations rise faster than your team headcount.

If those clocks drift out of sync, margins collapse. Short run vs long run is the key contrast here.

In the short run, demand spikes look like PMF.
In the long run, only contribution margin quality compounds.

What I Saw Running SlashML

This isn’t just theory for me. I saw it firsthand while building SlashML.

We closed multiple pilots, and most of the serious buyer interest looked less like “self-serve infra” and more like applied AI services for regulated industries.

That’s where a lot of the real money sits: compliance-heavy workflows, integration complexity, and customers who pay for outcomes, not just raw tokens.

We also got to about a few Ks in MRR from GPU reselling.

On paper, that looked like fast validation.

In practice, it was fragile economics. Those were not our GPUs, and we could tolerate thinner economics largely because AWS credits absorbed part of the hit. That is useful for learning, but it is not a durable long-term margin model.

If anything, that experience reinforced the core point: headline revenue is easy to celebrate; durable contribution margin is what determines whether you survive.

The Mechanism (If X, Then Y, Therefore Z)

1) If COGS is volatile, fixed pricing becomes a hidden liability

Your effective cost per token/image/second depends on:

• GPU contract structure

• model mix shifts

• latency SLO overprovisioning

• regional redundancy requirements

If your customer contracts are static while these inputs move, you are silently repricing your business downward.

2) If utilization swings, revenue quality diverges fast

Two providers can post similar monthly revenue and be in completely different realities.

• One runs a steady, committed base load.

• The other runs bursty, low-commit, support-heavy traffic.

Same revenue, different survivability.

3) If reliability expectations are cloud-level, operating expenses grows before pricing power does

Customers expect near-perfect uptime, predictable latency, instant incident response, and multi-region resilience.

They do not care that your company is 18 people.

So you staff and build like a much larger cloud org, but you bill like a startup fighting procurement comparisons.

4) If you are squeezed upstream and downstream, differentiation has to be real

• Upstream: model and infrastructure vendors can shift your cost base.

• Downstream: buyers benchmark and switch when they perceive parity.

If your pitch is “we host models too,” you are a line item, not a platform.

Therefore Z: consolidation is not an accident; it is the default equilibrium.

“But Demand Is Huge, So Isn’t This Fine?”

This is the strongest objection, and it’s worth taking seriously.

Yes, demand is huge. Yes, usage is growing. Yes, AI application teams need inference partners.

What this view gets right: the market is real.

What it misses: market growth does not forgive bad unit economics. It can actually hide them longer.

Growth can fund optimism.
Only margins fund survival.

“Can’t You Just Raise More?”

You can. Many do. The category has absorbed a lot of capital.

Approximate publicly reported funding (subject to change):

• Baseten: ~$500M+

• Together AI: $534M+

• Modal: ~$111M

• Hugging Face: ~$390M+

• fal: ~$500M+

• Fireworks AI: ~$327M+

• RunPod: ~$20M+

• Anyscale: ~$250M+
  

Capital helps, but capital is not a strategy.

It buys you time to fix pricing, improve mix, and productize reliability. If you don’t do those things, you are just purchasing a later failure date.

Implications for 2026

What reality changed?

Inference is no longer “GPU access with a dashboard.” It is an operations-and-economics game where small mistakes compound quickly.

What choices now exist?

• Path A: become a deeply integrated platform with pricing power and retention.

• Path B: optimize for strategic acquisition while still healthy.

• Path C: chase top-line growth without fixing economics and accept the likely outcome.

Who wins?

Teams that combine technical reliability with ability to raise more.

Who loses?

Teams that confuse demand with durability.

What likely happens next if actors behave rationally?

More consolidation, fewer true independents, and a clearer split between real platforms and commoditized capacity resellers.

Reading is something I enjoy, and I always feel like I started reading late, and have a lot to catch up on.

Therefore, one of the side quests, I decided on last year, which seemed doable was one book a month. The rule was pretty simple I had to finish one book a month. It doesn’t matter how much I had already read before-hand, I just have to close the loop and take some notes on the book.

The first few months were easy, I had multiple books in the pipeline that were more than 50% done. So the first few months was just ticking those off.

Once my backlog cleared, things became harder around May, where I literally finished “the mom test” at 11:45pm on May,31st. The second time things came close to almost-miss was in October, reading “The will to meaning” by Viktor Frankl.

Reading non-fiction was the hardest, as I had to take a bunch of notes, and I couldn’t read them more than 20 mins at a time. This made October really rough, because, “The will to meaning” is literally a collection of lectures. I had even read 40% of it before October, finishing the rest took me almost 25 days, with full focus on the last week. I almost thought about changing the book half-way through, but could not find any other book that I could finish in time.

I generally, laded on the book by the 2nd week, but sometimes I would make up my mind in the 3rd week.


Fiction and sci/fi were the easiest for me to read, although I wish I had more time with some of them. Especially Ted Chaings books of short stories. This is the best pieces of content I have ever read, will definitely be reading them again.


Finally, one book I didn’t expect I would like was, “how to get rich” by Felix Dennis. I thought it would be a trite biography with a list of steps. But it had that dark British self-depracating humourous tone, that I just could not put the book down. The prose is also super good. Even the advice was followed up with stories of something that actually happened to Felix personally. Would highly recommend to anyone wanting to start their own business.

Books

1. The Three-Body Problem (Book 1)

Finished: January 12, 2025
Liu Cixin - (10/10)

Amazing book, blown away by the storyline and the science. Captures incentives and human nature well.

2. Solomon’s Gold — The Baroque Cycle (Book 6)

Finished: January 20, 2025
Neal Stephenson - (7/10)

A bit long winded and introduction of characters not relevant to the story. Lots of MacGuffins, that were probably not required, at least as far as this book is concerned. Will have to see in the next books though. Better than volume 2, not worse than volume1. volume 1 book 1 is the best so far.

3. The Dark Forest (The Three-Body Problem, Book 2)

Finished: February 27, 2025
Liu Cixin - (8/10)

Started slow, the last 1/3rd was amazing. The science is a bit iffy though. But great application of game theory. Not sure if the author knew about the rand orgs research or not. Sad that a few well known character die. Probably the first time, I ve seen a novelist kill someone who was used as a POV person.

4. Poor Charlie’s Almanack

Finished: March 22, 2025
Charlie Munger - (8/10)

Amazing book, a bit dense, and repetition of ideas throughout the lectures. Someone who has read Influence by Cialdini will find the last half a condensed summary of the book. The Good thing is the author uses those as examples of how to apply them in practice.

5. Finite and Infinite Games

Finished: April 30, 2025
James P. Carse - (6/10)

Harder than expected. The book felt opaque until later chapters, when the idea of infinite games — especially when viewed through religion and culture — finally clicked. There’s something profound here, but it could have been much shorter. I’ll likely revisit it.

6. The Mom Test

Finished: May 31, 2025
Rob Fitzpatrick - (10/10)

Amazing book. Usually most non-fictions, I believe could be a blogpost. Not this one, this one can be 10 different blogposts. There wasn’t a single fluff in this book, every chapter was useful. I would change the ordering of the book a bit. But I think the author wanted to give the most value up-front.

7. Randomize

Finished: June 26, 2025
Andy Weir - (8/10)

A tight short story with a clever setup and satisfying math. I didn’t fully buy the ending, but the journey was fun and fast-paced.

8. Story of Your Life and Others

Finished: July 25, 2025
Ted Chiang - (10/10)

One of my fav books, especially “understand”, “story of your life”, and “hell is the absence of God”. This is right up there.

9. Pitch Anything

Finished: August 29, 2025
Oren Klaff - (7/10)

Somewhat useful, but stretched thin. The core ideas, frame control, hot vs. cold cognition, and enjoying the process, are solid, but could have been delivered in a long blog post. Worth skimming.

10. Do Androids Dream of Electric Sheep?

Finished: September 11, 2025
Philip K. Dick - (9/10)

Much better than the movie. The book’s obsession with empathy, artificial life, and moral ambiguity feels even more relevant now.

11. Exhalation

Finished: October 30, 2025
Ted Chiang - (10/10)

Amazing book loved it. Every single short story was on point. Following are notes on each.

• “The Merchant and the Alchemist’s Gate” 10/10 (great story on grief)

• “Exhalation” 9/10, the science is a bit iffy but great prose.

• “What’s Expected of Us” : shorter than expected, but loved the idea.

• “The Lifecycle of Software Objects”, 10/10, aboslutely loved it, will revisit

• “Dacey’s Patent Automatic Nanny”, 8/10, great idea, could have used some explanation.

• “The Truth of Fact, the Truth of Feeling”. 10/10, again amazing story about langauge and meaning.

• “The Great Silence”, 8/10, too short, but great ideas about comprehension, and what it means to be intelligent.

• “Omphalos”, 7/10, one of the ones that was too loose. More a question of philosophy than anything else.

• “Anxiety Is the Dizziness of Freedom” 10/10, a perfect short story, about free will, parallel universe

12. The Will to Meaning

Finished: November 31, 2025
Viktor Frankl - (6/10)

Extremely dense. This reads more like a lecture series on logotherapy than a narrative book. The central idea, finding meaning even in suffering and the mundane, is important, but the delivery is heavy. I took more notes than I could reasonably synthesize.

13. How to Get Rich

Finished: December 2025
Felix Dennis - (8/10)

Far more interesting as a warning than as advice. Dennis is blunt, funny, and unapologetic about the psychological cost of wealth. It’s less a how-to and more a reminder that money solves fewer internal problems than people expect.

Closing Thoughts

I’m increasingly drawn to sci-fi. Themes I like, are questions of meaning, agency, and intelligence.

A few lines that jump out in this review.

• Meaning isn’t discovered once, it’s continually constructed.

• Handstands on the edge of hell.

Will I do another one this year, 100%.

Full book list here