We pay more now, and that's great

In Part 1, I talked about the framework. Now, I’ll focus on hosting. I’ll cover the CMS in Part 3, and the order will make more sense once you see how everything fits together.

Our marketing site costs more each month now than it did before we migrated, and the difference is noticeable. The old setup used Astro on Lambda, stored assets on S3, had BunnyCDN in front, and used SES for the contact form. With about 4,000 visitors a month, that setup was nearly free. The new setup has a fixed monthly fee, and it’s clearly higher.

Still, I think this was the right move. I’d make the same choice even if our budget was smaller.

The bill that never appeared on an invoice

Look at the instruction file you use for your coding agents. Count how many rules are there just to make sure a deploy works as expected.

For me, there were eight rules for a deploy process that only had six steps.

What matters is the ratio, not the exact rules. The rules were standard: set the profile, purge the cache after updating assets, and check that the CDN serves the right files. Anyone who’s managed assets with a pull zone would expect these. What’s unusual is that six steps needed eight rules, because two rules were only there to handle silent failures in two steps.

Silent failures are the main issue here. People notice when something seems wrong, but an agent doesn’t. It just runs a command, gets an exit code and a lot of text meant for humans, and keeps going. All eight of my rules were really workarounds for the same problem: the old stack never told the agent, in a way it could understand, whether its action had succeeded. (Aïdasso et al., 2025)

Rules keep piling up. Each new failure adds another line, but not another step, and nothing stops this from growing. Over time, the file changes from describing the process to just patching over silent failures in the environment. It’s hard to notice this shift because you’re always editing the file for other reasons. (Schwartz, 2023)

I used to think the deploy process was simple, and I really believed it. It was simple for me. But those eight rules made it simple for me, not for anyone else. Now, "anyone else" includes the agents handling most of the routine work.

Better documentation is not the fix

This is the part I changed my mind about.

It’s easy to assume that having eight rules in an agent instruction file means the rules were poorly written, incomplete, or that the model just needed greater context. But that’s not the real problem, even though most advice suggests writing a better README.md, AGENTS.md, or CLAUDE.md, adding more context, or being clearer about constraints.

A rule that needs to be remembered at the right moment can just as easily be forgotten at the right moment. That happens to me late on a Friday, and it happens to an agent during a long session. No matter how clearly you write the rule, the real problem is knowing when it applies, not understanding it.

So the problem wasn’t that the rules were written badly. The real issue is that this kind of knowledge can’t be captured in rules at all. You can’t fix it with better prompts. You either change the environment so these issues never happen, or you keep facing the same problems.

A saturated market where the interesting differences hide

CI automation isn’t new. Teams have used AWS or custom scripts to run automated tests and deploys for years, and there are many vendors in this space. Vercel, Cloudflare Pages, and Amplify all offer Git-driven deploys, and if you compare their features, they seem very similar. I compared them that way too, and couldn’t find a reason to pick one over the others.

I chose Netlify not because of a feature list, but because of a personal conviction that grew over time. After following Netlify for a while, I felt they really understand what an agent-focused coding world needs, both in mindset and in practice. The two reasons that mattered most to me might sound almost too simple, but they were the ones that stuck.

First, the CLI and API always return structured output. For example, running "netlify deploy" gives you the deploy URL as JSON. Each deploy is an unchangeable snapshot, so if there’s a bad revision, it rolls back right away, and running the same command again sends a revision to the same URL. That could appear minor, but it’s not. It means an agent doesn’t have to guess if a deploy worked—it can read the URL, fetch it, and check the result. With Deploy Previews for every pull request, the agent gets a full feedback loop: change, deploy, read the URL, check it, and repeat. No one needs to click through a dashboard. Six of my eight rules existed because the old stack didn’t have this. They weren’t rewritten—they just weren’t needed anymore.

Second, there’s the MCP server. You add it with one command, and after that, the agent can use tool calls to operate the platform instead of running shell commands and parsing text. It can create and manage deploys, set environment variables, set up the database through extensions, and manage access controls. For any coding agent in 2026, this removes a whole set of failures I used to patch with rules—the ones where the agent had to guess platform settings because it couldn’t ask. Netlify also publishes its docs in agent-readable formats: an llms.txt index and installable skills for each platform feature, from Functions and Edge Functions to Blobs and netlify.toml. This prevents the agent from using outdated APIs or writing config files from memory. My last two rules were for exactly that problem, and now they’re gone too.

Neither of these features appears in a pricing table. But they’re the reason I stopped caring about the pricing table.

What the real cost actually buys

Most people compare unit prices—per GB, per request, per invocation—and by that measure, the old stack is cheaper. Object storage with a pull zone will always cost less than a managed platform. (Object Storage Pricing Comparison, 2025) If your main concern is unit price, don’t migrate.

But the real value of the new setup is the time it saves for engineers—and now, for agents too. The extra monthly cost is small compared to even a fraction of a developer’s day, and the work saved goes far beyond just my deploys. Every deploy an agent runs on its own saves time for the whole team.

The old stack’s hidden costs—extra time spent troubleshooting, unnecessary deploys, or watching over agents—never show up on an invoice. But over time, they add up. I thought the old stack was almost free, but the cost just showed up somewhere else.

What we’re really paying for isn’t just Git-driven deploys. It’s an environment that agents can check on their own. Now, an agent can push a branch, get a production build, read the preview URL as structured data, fetch the page, and confirm the change is live—no human needed. Before, only I could verify changes. Now, anyone—or anything—can.

Builds are real checkpoints. If there are uncommitted files, the build fails and the previous deploy stays live. Failures are clear and don’t cost anything. The agent sees a failed build with a reason, not a silent error. Credentials in the output stop the deploy completely. On the old stack, these problems would have shipped broken pages or gone unnoticed. (Vassallo et al., n.d.)

These features aren’t unique to this platform. They could be built somewhere else, but realistically, I never would have had the time. If I’m not going to build it, I don’t really have it. That’s why the real comparison isn’t in the pricing table.

The rule I would use next time

In a market where all vendors offer the same CI pipeline, I stopped asking which platform automates deploys. They all do. I am now asking which platform an agent can use without my help. The answer was the one where every command returns something a machine can read, and the platform is a set of tools an agent can use. Everything else on the feature list was just noise. That’s the rule I’d use next time, and it’s something you’ll never see on an invoice.

References

Aïdasso, H., Bordeleau, F. & Tizghadam, A. (2025). On the Illusion of Success: An Empirical Study of Build Reruns and Silent Failures in Industrial CI. arXiv preprint arXiv:2509.14347. https://doi.org/10.48550/arXiv.2509.14347

Schwartz, T. (January 13, 2023). Pipeline Sprawl in DevOps: It’s a Thing. Cloud Security Alliance. https://cloudsecurityalliance.org/blog/2023/01/13/pipeline-sprawl-in-devops-it-s-a-thing

(2025). Object Storage Pricing Comparison. Teleboas. https://teleboas.github.io/object-storage-comparison/

Vassallo, C., Schermann, G., Zampetti, F. & Romano, D. (n.d.). A Tale of CI Build Failures: An Open Source and a Financial Organization Perspective. https://www.researchgate.net/publication/320886283_A_Tale_of_CI_Build_Failures_An_Open_Source_and_a_Financial_Organization_Perspective