500 programmatic SEO pages and 11 APIs in 26 days. Here is the boring infrastructure that made it work.

I spent the last 26 days building what I call boring-saas-infra. Not a flashy AI wrapper. Not another no-code tool. Just the unglamorous plumbing every SaaS eventually needs: compliance checks, HS code classification, document parsing, finance validators, and watch engines.

Here is what actually shipped, what broke, and why the boring parts matter.

The numbers first

• 500 programmatic pages generated from a single generator.js script. Each page solves a tiny, specific problem (e.g., “HS code for laptop” → 8471.30).
• 11 APIs running on Cloudflare Workers. Some are REST. Two are MCP servers for AI agents.
• 200 URLs/day pushed to Google Indexing API. The script tracks progress in sent_urls.txt so it resumes exactly where it stopped.
• 1 SPA 404 bug fixed by switching to static output and a proper 404.html.
• CI/CD that deploys on every git push to Cloudflare Pages.

Why programmatic SEO works when you stop overthinking it

I did not write 500 articles by hand. I wrote three templates. Then I fed them a list of products and a mapping to HS codes.

node generator.js outputs:

• 500 static HTML pages
• A fresh sitemap.xml with 514 URLs
• Redirects and headers for Cloudflare

The entire SEO layer is a build step. No CMS. No database queries on the edge. Just static files.

The lesson: if you can describe the page with a template and a data row, you can generate it. The hard part is not the code. The hard part is deciding which 500 pages are worth generating.

The boring infrastructure that actually moved the needle

1. Google Indexing API (and respecting the 200/day quota)

I wrote a small Node script (index-api.cjs) that reads sitemap.xml, checks which URLs have already been sent, and pushes the next batch to Google’s Indexing API.

When it hits the 200/day limit, it stops cleanly and writes the progress to a text file. The next day, it picks up where it left off.

No fancy queue. No serverless cron. Just a file and a while loop.

2. Suby for monetization (without building a billing system)

I did not want to integrate Stripe, handle tax, and build a customer portal. Suby gave me checkout links in minutes.

The site now embeds Suby checkout URLs for:

• Finance Tools Pro ($19.99/month)
• Compliance Suite ($99/month)
• PEP Database CSV (coming soon)

Each link is just an <a href="...">. No SDK. No webhook handling. If you are a solo developer, this is the fastest path from “useful API” to “someone can pay you.”

3. MCP servers for AI agents

Two of the APIs are also exposed as MCP servers:

• document-to-json-mcp
• watch-engine-mcp

Agents can discover them in marketplaces and call them without an API key. For a small infra project, this is a distribution channel that did not exist two years ago.

What I would do differently

• Do not automate the browser if you can automate the API. I wasted hours trying to scrape a dashboard with Puppeteer. The API (and a canonical URL) was the right answer.
• Fix the canonical URL before you syndicate. If you cross-post without canonical_url, Dev.to and Medium will outrank your own domain[reference:1]. This is not optional.
• Ship the boring things first. The 404 page, the sitemap, the deploy script, the llms.txt file — these do not feel like “product,” but they are what makes the product findable.

What is next

Day 27–29 is distribution: Dev.to, Medium, X, and AI directories. If you are building something boring but useful, the distribution is the hard part. The code is the easy part.

The site is live at boring-saas-infra.pages.dev. If you want to see the generated pages, start with the HS code catalog.

---

Originally published at boring-saas-infra.pages.dev.