DEV Community: Oleksandr

I built 100 compliance screening pages with one command (OFAC, PEP, entity)

Oleksandr — Sat, 10 Oct 2026 06:16:05 +0000

This is the 5th stream in a series. Previous ones: HS codes, document parsing, finance validators, watch/monitoring. This time — compliance screening against OFAC, EU, UK, UN sanctions lists, plus PEP screening and entity verification.

Same playbook each time: one Cloudflare Worker + one JSON list + one generator script → 100 SEO pages + landing + Suby product.

Live: https://jsonexlab.com/compliance

What it does

Screen any person or company against:

OFAC SDN (US Treasury, 19,416 entries)
OFAC Consolidated (non-SDN)
UK OFSI (UK sanctions)
EU Consolidated (EU sanctions)
UN Security Council (UN sanctions)
PEP (Politically Exposed Persons)
Entity verification (company registries: US-DE, UK, DE, UA, etc.)

Live demo:

curl "https://compliance-engine.boring-saas-infra.workers.dev/check/sanctions?q=Rosneft"

→

{
  "check_type": "SANCTIONS",
  "query": "Rosneft",
  "status": "HIT",
  "matches": true,
  "results": [
    {
      "list": "OFAC_SDN",
      "name": "OPEN JOINT-STOCK COMPANY ROSNEFT OIL COMPANY",
      "type": "entity",
      "country": "Russia",
      "programs": ["UKRAINE-EO13662", "RUSSIA-EO14024"],
      "ids": [
        {"type": "Registration ID", "number": "1027700043502"},
        {"type": "Tax ID No.", "number": "7706107510"},
        {"type": "Website", "number": "www.rosneft.com"}
      ],
      "addresses": [{"street": "26/1 Sofiyskaya Embankment", "city": "Moscow", "country": "Russia"}],
      "score": 1
    }
  ]
}

Why this one was harder

Three things made this stream different from previous ones:

1. Cloudflare Workers cannot fetch OFAC directly

OFAC lives on sanctionslistservice.ofac.treas.gov. Cloudflare Workers fails with HTTP 525 (SSL handshake error) or 403 (missing User-Agent). This is a TLS incompatibility on the origin side — nothing you can fix from the Worker.

Solution: move ingestion to GitHub Actions (6 GB RAM, normal TLS stack, works with any URL).

2. 30 MB XML doesn't fit in 128 MB Worker RAM

Naive approach — fetch XML → parse → insert — dies with error 1102 (Worker exceeded resource limits).

Solution: GitHub Actions downloads the XML, parses it in Node.js, and inserts directly into Cloudflare D1 via the D1 HTTP API.

3. D1 free tier has a daily row-write limit

100,000 row writes per day. A single OFAC ingestion = 19,416 rows × 2 (UPSERT counts as insert + update) = ~39,000 writes. Two ingestions in one day → quota hit.

Solution: cron runs once per day at 01:00 UTC. Quota resets at midnight UTC, so the ingestion always fits.

The architecture

GitHub Actions (cron 0 1 * * *)
    │
    ├── Download OFAC SDN XML (30 MB) via curl
    ├── Download UK OFSI CSV (50 MB) via curl
    ├── Parse in Node.js (6 GB RAM available)
    └── POST to Cloudflare D1 HTTP API
            │
            ▼
    Cloudflare D1 (compliance-db)
        ├── sanctions (19,416+ entries)
        ├── pep
        ├── entity
        ├── license
        ├── runs (ingestion log)
        └── search_log
            │
            ▼
    Cloudflare Worker (compliance-engine)
        ├── GET /check/sanctions?q=...
        ├── GET /check/pep?q=...
        ├── GET /check/entity?q=...
        ├── GET /stats
        └── Cron triggers (legacy, not used)
            │
            ▼
    Cloudflare Pages (jsonexlab.com)
        ├── /compliance (landing)
        ├── /compliance/{slug} (100 SEO pages)
        └── /sitemap.xml (729 URLs)

The GitHub Actions workflow

.github/workflows/ingest-ofac.yml:

name: Ingest OFAC Sanctions

on:
  schedule:
    - cron: '0 1 * * *'
  workflow_dispatch:

jobs:
  ingest:
    runs-on: ubuntu-latest
    timeout-minutes: 30

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Run OFAC ingestion
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
        run: node scripts/ingest-ofac.js

Simple. GitHub Actions does the heavy lifting, Worker stays light.

The parser

Core is the OFAC SDN XML parser — regex-based, no dependencies:

function parseOneSdnEntry(entry, listCode = "OFAC_SDN") {
  const uid = extractTag(entry, "uid");
  if (!uid) return null;

  const lastName = decodeXmlEntities(extractTag(entry, "lastName") || "");
  const firstName = decodeXmlEntities(extractTag(entry, "firstName") || "");
  const fullName = [firstName, lastName].filter(Boolean).join(" ").trim() || lastName;
  if (!fullName) return null;

  const type = mapSdnType(extractTag(entry, "sdnType") || "Entity");
  const programs = extractAllTags(entry, "program");

  // aliases, ids, addresses, nationality, dob...

  return {
    list_code: listCode,
    entity_id: uid,
    name: fullName,
    name_normalized: normalizeName(fullName),
    aliases: aliases.length ? aliases : null,
    type,
    country,
    programs: programs.length ? programs : null,
    dob,
    ids: ids.length ? ids : null,
    addresses: addresses.length ? addresses : null,
    remarks: remarks || null,
  };
}

Whole parser is ~250 lines. Handles:

19,416 SDN entries
Aliases (aka blocks)
IDs (passport, tax, registration, website, email)
Addresses (multiple per entity)
Nationality / citizenship
Date of birth

Gotcha I hit: extractAllTags initially captured nested XML tags. <programList><program>CUBA</program></programList> returned ["<program>CUBA"] instead of ["CUBA"]. Fix: strip nested tags with .replace(/<[^>]+>/g, "").

The fuzzy matching

For a compliance tool, exact string matching is useless — you need fuzzy. Here's what I use in the Worker:

function matchScore(queryNorm, candidateNorm) {
  const jw = jaroWinkler(queryNorm, candidateNorm);
  const tok = tokenSimilarity(queryNorm, candidateNorm);
  const lev = levenshtein(queryNorm, candidateNorm);
  const levScore = 1 - lev / Math.max(queryNorm.length, candidateNorm.length);
  return 0.5 * tok + 0.35 * jw + 0.15 * levScore;
}

Three algorithms weighted:

Token similarity (0.5) — handles word order ("Rosneft Oil Company" vs "Oil Company Rosneft")
Jaro-Winkler (0.35) — handles typos and short strings
Levenshtein (0.15) — tie-breaker

Plus normalization before matching:

Lowercase
ASCII-fold (Cyrillic → Latin: Олександр → oleksandr)
Strip punctuation
Remove legal suffixes (LLC, Inc, GmbH, PJSC, etc.)
Collapse whitespace

Threshold 0.82 by default. Rosneft → OPEN JOINT-STOCK COMPANY ROSNEFT OIL COMPANY scores 1.0 (100% match). Gazprom → CLEAR (correct — Gazprom itself isn't on SDN, but Gazprombank and Gazpromneft are).

The 100 SEO pages

products-compliance.json (excerpt):

[
  {"slug":"sanctions-ofac-sdn","name":"OFAC SDN Sanctions Check","type":"sanctions","category":"Sanctions","list_code":"OFAC_SDN"},
  {"slug":"sanctions-ofac-sdn-individuals","name":"OFAC SDN — Individuals","type":"sanctions","type_filter":"individual"},
  {"slug":"sanctions-russia","name":"Russia Sanctions Screening","type":"sanctions","program_filter":"RUSSIA"},
  {"slug":"pep-head-of-state","name":"PEP — Head of State","type":"pep","level":"head_of_state"},
  {"slug":"entity-verify-llc","name":"LLC Entity Verification","type":"entity","entity_type":"LLC"},
  {"slug":"verify-medical-license","name":"Medical License Verification","type":"license","license_type":"medical"}
]

100 entries across 5 categories:

30 Sanctions — by list (OFAC SDN, EU, UK, UN) + by type (individual, entity, vessel, aircraft) + by program (Russia, Iran, DPRK, Cuba, etc.)
20 Licenses — medical, nursing, legal, contractor, real estate, insurance, accounting, pharmacy, dental, etc.
20 Checklists — country + segment (Germany import, US export, fintech, crypto, healthcare, etc.)
15 PEP — head of state, minister, parliament, judiciary, military, SOE executive, etc.
15 Entity — LLC, Corp, PLC, Ltd, GmbH, AG, SA, SARL, BV, NV, Oy, AB, Pty, LLP, ТОВ

generator-compliance.cjs:

node generator-compliance.cjs

→

✅ Згенеровано 100 сторінок у output/compliance/
✅ sitemap.xml оновлено — всього 729 URL
✅ llms.txt оновлено — 100 compliance checks

Each page has:

Unique <title> + meta description
Working live demo (hits real Worker with real D1 data)
Schema.org Product + BreadcrumbList + FAQPage
5 FAQ items customized per check type
Related checks chips
Pricing block with Suby checkout

Pricing

Free — 5 checks/day, no API key
Pro ($99/mo) — 500 checks/mo, all 5 lists, PEP, entity, license, webhooks

Higher price than other streams ($19.99) because:

Recurring compliance need (regulatory requirement)
B2B audience pays more
Different value prop (legal risk mitigation, not a one-shot check)

Deployment

Two Cloudflare accounts came in handy:

Account #1 — jsonexlab.com (custom domain) + Pages project
Account #2 — Workers + D1 + R2 + KV

Workers stay on *.boring-saas-infra.workers.dev, Pages on jsonexlab.com. Clean separation.

Full stack

Cloudflare Workers — API (compliance-engine, finance-validators, watch-engine)
Cloudflare D1 — SQLite storage (compliance-db: 19,416+ sanctions)
Cloudflare R2 — raw file buffer (not actively used — kept as fallback)
Cloudflare KV — response cache
Cloudflare Pages — static site (729 URLs)
GitHub Actions — daily ingestion (OFAC + UK OFSI)
Node.js generators — no deps, ~300 lines each
Suby — payments (crypto + card)
IndexNow — 729 URLs pinged to Bing + Yandex

Total monthly cost: $0.

What's next

EU + UN ingestion — currently only OFAC + UK
PEP data — WikiData + OpenSanctions (needs commercial licence)
Webhook alerts — get notified when a party on your list gets sanctioned
Google Sheets add-on — =SANCTIONS_CHECK(A1)

Try it

If you're building KYC, AML, or trade compliance workflows — give it a shot. Free tier is genuinely free.

Happy to answer questions about the Cloudflare Workers + D1 + GitHub Actions setup, or the programmatic SEO pattern.

I built a currency & VAT monitoring system with Cloudflare Workers

Oleksandr — Thu, 08 Oct 2026 14:26:53 +0000

Three streams shipped this week:

100 document parsers with one command
100 finance validators with one command
100 monitoring pages — and this one needs a Worker with cron, KV, and webhooks

Let me show you how the monitoring one works.

What it does

Watch monitors two things daily:

Currency rates — NBU official rates (44 currencies) + ECB via Frankfurter
EU VAT rates — 27 member states, standard and reduced rates

When a value changes beyond the threshold, it fires a webhook + email alert. No dashboards to check.

Live landing: https://boring-saas-infra.pages.dev/watch

Example page: https://boring-saas-infra.pages.dev/watch/vat-watch-germany

Why monitoring is harder than validation

The first two streams were stateless: request → response → forget.

Monitoring is stateful:

A cron must run daily even when nobody is using the API
We need to remember yesterday's value to detect changes
We need to store subscriptions (who watches what)
We need to deliver alerts (webhook + email)

That's exactly what Cloudflare Workers + KV + Cron Triggers give you.

The architecture

One Worker, one KV namespace, one cron job.

watch-engine.boring-saas-infra.workers.dev
  ├── GET  /currency/nbu              ← live NBU rates
  ├── GET  /currency/frankfurter      ← live ECB rates
  ├── GET  /vat/:country              ← VAT snapshot for one country
  ├── GET  /watch/list                ← list all watches
  ├── POST /watch/create              ← create a watch
  ├── DELETE /watch/:id               ← delete a watch
  └── GET  /cron/run                  ← manual cron trigger (for testing)

Cron: 0 6 * * *                       ← runs every day at 06:00 UTC

The wrangler.toml

name = "watch-engine"
main = "src/index.js"
compatibility_date = "2026-10-08"

[[kv_namespaces]]
binding = "WATCH_KV"
id = "021f939116ae416bb35703daa1e2c74d"
preview_id = "021f939116ae416bb35703daa1e2c74d"

[triggers]
crons = ["0 6 * * *"]

That's the entire infrastructure. No database, no message queue, no VPS.

The data sources

For currency — three of them:

// NBU — official Ukrainian rates
async function fetchNBU() {
  const r = await fetch("https://bank.gov.ua/NBUStatService/v1/statdirectory/exchange?json");
  const data = await r.json();
  const rates = {};
  for (const row of data) rates[row.cc] = { rate: row.rate, name: row.txt };
  return { source: "NBU", base: "UAH", rates };
}

// Frankfurter — free ECB wrapper
async function fetchFrankfurter(base = "USD") {
  const r = await fetch(`https://api.frankfurter.app/latest?from=${base}`);
  const data = await r.json();
  return { source: "Frankfurter", base: data.base, rates: data.rates };
}

Both are free, no API key, stable JSON.

For VAT — a snapshot map of 27 countries:

const VAT_SNAPSHOT = {
  updated: "2026-10-08",
  countries: {
    DE: { standard: 19, reduced: [7] },
    FR: { standard: 20, reduced: [2.1, 5.5, 10] },
    IT: { standard: 22, reduced: [4, 5, 10] },
    // ... 24 more
  }
};

The cron compares the current snapshot with yesterday's stored value. If a rate changed, it fires an alert. VAT rates change rarely (a few times per year per country), so this is cheap and effective.

Change detection

The whole point of a monitoring system is to not alert on every run. Only when something actually changes.

async function runCron(env) {
  const alerts = [];

  // Currency: compare with previous snapshot
  const nbu = await fetchNBU();
  const prev = await getSnapshot(env, "currency:NBU");

  if (prev) {
    for (const [cc, cur] of Object.entries(nbu.rates)) {
      const old = prev.rates[cc];
      if (old && Math.abs(old.rate - cur.rate) / old.rate > 0.005) {
        alerts.push({
          type: "CURRENCY_CHANGE",
          currency: cc,
          from: old.rate,
          to: cur.rate,
          change_pct: ((cur.rate - old.rate) / old.rate * 100).toFixed(2),
        });
      }
    }
  }

  await saveSnapshot(env, "currency:NBU", nbu);

  // VAT: only fires when the snapshot's `updated` date changes
  // ...

  return { alerts };
}

Threshold for currency: 0.5%. Anything smaller is noise.

The webhook alert format

{
  "type": "VAT_CHANGE",
  "country": "DE",
  "from": "19%",
  "to": "20%",
  "effective": "2026-01-01",
  "source": "EU Commission TEDB",
  "ts": "2026-10-08T14:21:33.181Z"
}

POSTed to whatever URL you configured. Works with:

Slack incoming webhooks
Discord webhooks
n8n / Zapier / Make.com
Your own backend

The 100 SEO pages

Same pattern as the previous two streams.

products-watch.json (excerpt):

[
  {"slug":"currency-watch-uah-usd","name":"UAH/USD Currency Watch","type":"currency","category":"Currency","pair":"UAH/USD","source":"NBU"},
  {"slug":"vat-watch-germany","name":"German VAT Watch","type":"vat","category":"VAT","country":"DE","country_name":"Germany"},
  {"slug":"vat-watch-eu-standard","name":"EU Standard VAT Watch","type":"vat","category":"VAT","country":null,"country_name":"EU"}
]

100 entries:

50 currency pairs — UAH pairs (25) + ECB/Frankfurter pairs (25)
50 VAT watches — 27 countries + 23 EU-wide categories

generator-watch.cjs reads the JSON, renders templates/watch-detail.html, writes 100 folders, updates sitemap.xml and llms.txt.

node generator-watch.cjs

→

Generated 100 pages in output/watch/
sitemap.xml updated — 628 URLs total
llms.txt updated — 100 monitors

Each page has a live demo hitting /currency/nbu or /vat/:country — so visitors see real data, not a mock.

Pricing

Free — 1 active watch, daily check, email alerts
Pro ($29.99/mo) — 100 watches, webhooks, priority checks

Different price from the previous streams because monitoring is recurring value — customers stay subscribed.

Stack

Cloudflare Workers (API + cron)
Cloudflare KV (state)
Cloudflare Pages (static pages)
Node.js generators (no deps)
Suby (payments)
IndexNow (search ping)

Total monthly cost so far: $0.

What's next

Tariff Watch — US ITC / EU TARIC / UK Trade Tariff changes
Sanctions Watch — OFAC / EU / UK OFSI lists
HS Code Watch — WCO Harmonized System updates

Same architecture, just more data sources.

Try it

Landing: https://boring-saas-infra.pages.dev/watch
Example page: https://boring-saas-infra.pages.dev/watch/vat-watch-germany
Live NBU rates: https://watch-engine.boring-saas-infra.workers.dev/currency/nbu
Live VAT for Germany: https://watch-engine.boring-saas-infra.workers.dev/vat/DE

If you're building KYC, tax, or finance tooling and need alerts on rate/rate changes — the free tier is genuinely free.

Happy to answer questions about Cloudflare Workers + KV + cron, or the programmatic SEO side.

I built 100 finance validators with one command

Oleksandr — Thu, 08 Oct 2026 13:34:46 +0000

Two days ago I shipped 100 document parsers with one command. Yesterday I did 100 finance validators. Same playbook.

The pattern

Build a small API (Cloudflare Worker)
Write a JSON list of 100 keywords
Template + generator script → 100 SEO pages
Sitemap + IndexNow → 527 URLs pinged to Bing/Yandex
Landing page with a live demo
Pricing via Suby (crypto + card)

This works because:

Each of the 100 pages targets a specific search query
Each page has unique content (own examples, own FAQ, own schema)
Zero cost per page — Cloudflare Workers free tier handles everything
Total build time: ~2 hours

What I built this time

Finance Tools — 5 validators behind one API:

IBAN (80+ countries, mod-97 checksum)
EU VAT (format for 28 countries)
SWIFT/BIC (bank + country + location + branch)
LEI (ISO 17442, mod-97-10)
Credit cards (Luhn + brand detection: Visa, Mastercard, Amex, Discover, JCB, Diners, Maestro, UnionPay)

Live landing: https://boring-saas-infra.pages.dev/finance-tools

Try it (no signup):

curl "https://finance-validators.boring-saas-infra.workers.dev/iban?value=DE89370400440532013000"

→

{
  "valid": true,
  "iban": "DE89370400440532013000",
  "country_code": "DE",
  "check_digits": "89",
  "bban": "370400440532013000",
  "length": 22
}

The 100 pages

Each of these has its own page at /validate/{slug}:

30 IBAN validators — one per country (Germany, France, UK, Spain, Italy, Netherlands, Belgium, Switzerland, Poland, …)
20 VAT validators — Germany, France, UK, Italy, Spain, Netherlands, Belgium, Austria, Poland, …
20 SWIFT validators — USA, UK, Germany, France, Switzerland, Japan, China, Singapore, Hong Kong, …
15 LEI validators — bank, corporation, fund, insurance, broker, government, nonprofit, …
15 card validators — Visa, Mastercard, Amex, Discover, JCB, Diners, Maestro, UnionPay, Luhn, …

Example pages:

Each page has:

Unique <title> + meta description
Its own sample input and sample JSON output
cURL example customized to that validator
5 FAQ items
Schema.org Product + BreadcrumbList + FAQPage
Working live demo hitting the real API
Related validator chips

The generator

products-finance.json (excerpt):

[
  {"slug":"validate-iban","name":"IBAN","type":"iban","category":"IBAN"},
  {"slug":"validate-iban-germany","name":"German IBAN","type":"iban","category":"IBAN","country":"DE","sample":"DE89370400440532013000"},
  {"slug":"validate-vat-germany","name":"German VAT","type":"vat","category":"VAT","country":"DE","sample":"DE123456789"},
  {"slug":"validate-visa","name":"Visa","type":"card","category":"Card","sample":"4111111111111111"}
]

generator-finance.cjs does the rest:

node generator-finance.cjs

→

Generated 100 pages in output/validate/
sitemap.xml updated — 527 URLs total
llms.txt updated — 100 validators

The Worker

Single Cloudflare Worker, 5 endpoints. Core IBAN mod-97:

function mod97(str) {
  const rearranged = str.slice(4) + str.slice(0, 4);
  let expanded = "";
  for (const ch of rearranged) {
    const code = ch.charCodeAt(0);
    expanded += (code >= 48 && code <= 57) ? ch : (code - 55).toString();
  }
  let remainder = 0;
  for (const ch of expanded) {
    remainder = (remainder * 10 + parseInt(ch, 10)) % 97;
  }
  return remainder;
}

LEI uses a slightly different algorithm (mod-97-10), cards use Luhn, SWIFT is length + format. Whole worker is ~250 lines.

Pricing

Free — 50 validations/day, no API key
Pro — $19.99/mo, 5,000 validations, batch, VIES lookup for VAT

Stripe alternative: Suby. Crypto + card. Live in 5 minutes.

Stack

Cloudflare Workers (API)
Cloudflare Pages (static pages)
Node.js generators (no deps)
IndexNow (ping Bing/Yandex)
Suby (payments)

Total cost: $0.

What's next

Google Sheets add-on: =VALIDATE_IBAN(A1)
Bulk validation endpoint
VIES integration for Pro tier
Two more programmatic streams: Monitoring, Compliance

Try

Landing: https://boring-saas-infra.pages.dev/finance-tools
Example page: https://boring-saas-infra.pages.dev/validate/validate-iban
API: https://finance-validators.boring-saas-infra.workers.dev

If you're building KYC, SEPA, VAT, or checkout flows — the free tier is genuinely free.

Happy to answer questions about the programmatic SEO setup, the generators, or the Worker code.

I turned 100 document types into JSON with one command

Oleksandr — Thu, 08 Oct 2026 12:07:07 +0000

Last week I shipped a programmatic SEO site that turns any product name into its HS code — 320 pages, one command, zero manual work.

Today I did the same thing for documents.

The problem

Every B2B team needs to pull structured data out of documents:

Invoices → line items, tax, totals, vendor, customer
Receipts → merchant, items, payment method
Contracts → parties, term, governing law, termination clauses
Bills of lading → shipper, consignee, containers, ports
Offer letters → candidate, salary, start date
Lab reports → test, result, units, reference range
…and 94 more types

Existing OCR APIs either:

Cost $0.10+ per document with a $500/mo minimum
Require you to train a custom model per document type
Return garbage on layout variations

What I built

Docs-to-JSON — one endpoint, 100+ document types, clean JSON back in ~2 seconds.

Try it: https://boring-saas-infra.pages.dev/document-to-json

Live demo (no signup):

curl -X POST https://document-to-json.boring-saas-infra.workers.dev/extract \
  -H "Content-Type: application/json" \
  -d '{
    "document_type": "invoice",
    "text": "INVOICE #INV-2043\nDate: 2026-03-14\nVendor: Acme Supplies Ltd.\n..."
  }'

Returns:

{
  "document_type": "invoice",
  "fields": {
    "invoice_number": "INV-2043",
    "date": "2026-03-14",
    "vendor": "Acme Supplies Ltd.",
    "customer": "Brightline Imports Inc.",
    "subtotal": 925.00,
    "tax": 92.50,
    "total": 1017.50,
    "currency": "USD",
    "line_items": [
      {"description": "Copper wire, 2mm", "qty": 120, "unit": "m", "unit_price": 4.50},
      {"description": "Steel fittings, 3/4\"", "qty": 40, "unit": "pcs", "unit_price": 7.25}
    ]
  }
}

The distribution play

Same playbook as the HS Codes stream:

Product page with live demo — /document-to-json
100 SEO landing pages — /document-type/invoice-to-json, /document-type/contract-to-json, /document-type/lab-report-to-json, etc.
Programmatic generation — one JSON config + one template + one generator script
Sitemap ping via IndexNow — 426 URLs to Bing/Yandex in one call

The generator

products-docs.json (excerpt):

[
  {"slug":"invoice-to-json","name":"Invoice","category":"Finance"},
  {"slug":"contract-to-json","name":"Contract","category":"Legal"},
  {"slug":"bill-of-lading-to-json","name":"Bill of Lading","category":"Logistics"},
  {"slug":"offer-letter-to-json","name":"Offer Letter","category":"HR"},
  {"slug":"lab-report-to-json","name":"Lab Report","category":"Medical"}
]

generator-docs.cjs reads the JSON, loops over 100 entries, injects them into a single template, writes 100 folders, updates sitemap.xml and llms.txt.

That's it. One command:

node generator-docs.cjs

Output:

✅ Згенеровано 100 сторінок у output/document-type/
✅ sitemap.xml оновлено — всього 426 URL
✅ llms.txt оновлено — 100 типів документів

SEO structure of each page

Every one of the 100 pages includes:

Unique title + meta description
Schema.org Product + BreadcrumbList + FAQPage
Input sample (raw document text) and output sample (structured JSON)
cURL example with document_type=<slug>
Pricing block
5 FAQ items specific to that document type
Related document type chips

Zero duplicate content. Each page has its own example tailored to the document type — invoices get invoice samples, contracts get contract samples, lab reports get lab samples.

Pricing

Free — 50 extractions/day, all 100+ document types, REST API
Pro — $19.99/mo, 5,000 extractions, priority queue, email support

Stripe alternative: Suby (crypto + card, instant setup).

Tech stack

Worker — Cloudflare Workers (already deployed)
Landing + 100 SEO pages — static HTML on Cloudflare Pages
Generator — Node.js, no dependencies
Deploy — wrangler pages deploy output
Sitemap ping — IndexNow (Bing + Yandex)

Whole thing ran end-to-end in under 2 hours.

What's next

Google Sheets add-on: =DOC2JSON(A1)
MCP server for AI agents to call the API directly
3 more programmatic streams: Finance, Monitoring, Compliance

Try it

Landing: https://boring-saas-infra.pages.dev/document-to-json
Example SEO page: https://boring-saas-infra.pages.dev/document-type/invoice-to-json
API: POST https://document-to-json.boring-saas-infra.workers.dev/extract

If you're processing documents at any scale and don't want to pay $$$/mo for OCR — give it a shot. Free tier is genuinely free.

Happy to answer questions about the programmatic SEO setup, the generator, or the worker in comments.

I generated 320 SEO pages with one command. Here's the full stack (and what broke).

Oleksandr — Thu, 08 Oct 2026 07:22:31 +0000

Three days ago I published a post about deploying 35 MCP servers in 10 days. It got some attention, but the honest takeaway was: 0 revenue, 0 users, 35 perfectly configured servers. Configuration is not distribution.

This is the follow-up. Three days later, here's what actually changed.

The number that matters
220 to 320 SEO pages.

Not manually written. Generated with one command.

The command reads products.json (320 products), calls my own HS Codes API for each product, fills an HTML template, and writes 320 static pages into the output directory. It also generates sitemap.xml, llms.txt, and a catalog index.

Then two more commands: deploy to Cloudflare Pages, and submit all URLs to IndexNow.

Three commands. 320 pages live. 325 URLs submitted to Google, Bing, Yandex, and Seznam.

What I learned about SEO at scale

Schema.org is not optional.

Every page has four JSON-LD blocks: Product (with the HS code as SKU), BreadcrumbList, WebSite with SearchAction, and FAQPage with three real questions per page.

Why does this matter? Because Google's rich results show breadcrumbs, product info, and FAQ snippets. That's free real estate in search results. You can validate any page at search.google.com/test/rich-results. My pages pass cleanly.

Cloudflare Pages does clean URLs by default.

I didn't know this until I tested it. Requesting /pages/terms.html returns a 308 redirect to /pages/terms. Requesting /pages/terms returns 200 OK.

This means you should never link to .html in your sitemap or internal links. Google treats redirects as a minor signal, but you lose a tiny bit of link equity on every hop.

The fix is one file: _redirects in the root, with one line. That's it. Now every .html request gets a clean 308 redirect to the canonical clean URL.

IndexNow is the fastest way to notify search engines.

Google has Search Console. Bing has IndexNow.

IndexNow is an open protocol that lets you push URLs directly to Bing, Yandex, Seznam, and Naver. No crawling queue, no waiting for sitemap processing.

I submitted 325 URLs yesterday. Today, Bing shows the site in site: search.

What broke (the honest part)
Product Hunt failed.

I launched HS Codes Classifier on October 1st. It got 1 upvote. Not featured. The launch was effectively invisible.

Why? Because Product Hunt rewards existing audience, timing, and hunter relationships. I had none of the three.

I'm not re-launching. I'm focusing on channels that don't require pre-existing audience: search engines, organic distribution, and technical content like this post.

Suby cards are blocked for Ukraine.

I set up Suby (a Ukrainian crypto payment provider) to accept USDC for my $9.99/month Pro tier. The crypto checkout works. But cards are blocked for Ukrainian accounts. Suby requires a business entity in a supported jurisdiction.

Workaround: I'm looking at AgentaOS, a Merchant of Record that supports more countries. That verification is still in progress.

AgentaOS verify was rejected.

They asked for three things: branded support email at my own domain, live product proof, and proof of how customers receive their Pro API key. Fair feedback. I'm buying a domain this week and fixing all three.

What is actually working
The infrastructure, finally.

Three days ago, my dashboards were empty. Today: 1,459 API calls in 24 hours, 215 LLM calls to OpenAI, 0 errors across all workers. Sentry catches errors before users see them. UptimeRobot monitors 4 endpoints with 100% uptime. Ops Bot sends a daily digest at 9:00 AM Kyiv time.

Git backup, for the first time.

Before this week, my entire hs-seo project lived on a single laptop. If the drive failed, I would lose everything. Now there are 3 private GitHub repos: hs-seo, ops-bot, call-counter. Every code change is committed. The output directory with all 320 HTML files is regenerable from products.json and generator.js.

Google Sheets Add-on, submitted for review.

I built =HSCODE("laptop computer") as an Apps Script function. It returns 8471.30 in any cell. Then I created a GCP project, set up OAuth consent screen, enabled Workspace Marketplace SDK, and submitted for review.

Status: in review. If approved, this becomes a distribution channel. 3 billion Google Sheets users can install it.

The uncomfortable truth
Configuration is still not distribution.

I have 320 pages, and Google has indexed zero of them. Bing has indexed a handful. Yandex nothing yet.

That is normal. Google's crawl queue processes new sites slowly. Based on experience: Week 1 to 2 for the first pages, Week 3 to 4 for most pages, Month 2 to 3 for first organic impressions, Month 4 to 6 for first organic traffic.

The infrastructure is ready. Now it is a waiting game.

Meanwhile, I am not waiting idle. This week: Revenue Bot (Telegram notification on every new payment), PostHog (funnel analysis from Landing to Payment), Langfuse (LLM observability with prompt, response, cost, latency).

What I would tell my past self
Start with distribution, not infrastructure.

I spent 10 days building 35 MCP servers. If I had spent 2 days building one server and 8 days marketing it, I would probably have 10 paying users by now.

The infrastructure is a trap. It feels productive. It is not.

Ship on channels that do not require permission.

Product Hunt needs a hunter. Reddit needs karma. HN needs luck. But search engines do not need anything. You publish, they index. Given enough pages and enough time, organic traffic compounds.

Every page needs to answer a question.

"HS code for laptop" is a question. My page answers it in 2 seconds with a real HS code, a confidence score, and a reasoning paragraph. That is the entire value proposition. No marketing required.

The metrics that matter are not the metrics you see daily.

Daily API calls do not pay rent. Monthly recurring revenue does. I keep forgetting this.

What is next
Immediate: buy a domain, unlock Email Routing and AgentaOS. Resubmit AgentaOS verify with branded email. Get Google to index the first 50 pages via URL Inspection.

This week: PostHog, Langfuse, Revenue Bot. Google Sheets Add-on approval (hopefully). First Dev.to backlink chain.

This month: 500+ SEO pages. Real organic traffic from Google. First $9.99 payment.

I will write the next update when the first payment comes in, or when the wait becomes long enough that I need to write about it anyway.

Try it
Google Sheets: open a new sheet, go to Extensions, Apps Script, paste the code from my GitHub. Then in any cell: =HSCODE("iPhone 15 Pro"). You will get 8517.12.

API: https://hs-codes-classifier.boring-saas-infra.workers.dev/dev-classify — POST with a description field. Free, 50 calls per day.

Catalog: https://boring-saas-infra.pages.dev/catalog — 320 products, each with an HS code.

Pricing: https://boring-saas-infra.pages.dev — Free tier, $9.99 per month Pro.

If you have found a distribution channel that actually works for indie products in 2026, I would love to hear about it. I am still searching.

I deployed 35 MCP servers in 10 days. Here's what nobody tells you about AI monetization

Oleksandr — Mon, 05 Oct 2026 08:38:58 +0000

Last week I shipped 26 MCP servers in 2 days. This week I'm at 35 servers, a Google Sheets add-on, and a full x402 payment stack.

Revenue so far: $0.

Not because nothing works. Everything works. Every server is deployed, every paywall responds, every API returns the right answer. The problem is different — and it's the thing nobody talks about when they write about AI monetization.

The reality check

When I started building MCP servers, I genuinely believed the hard part was technical. Get the server running, wire up x402 for agent payments, publish to the marketplace, done. The money should follow.

Here's what actually happened:

35 MCP servers are live on MCPize with SEO, logos, pricing, and marketplace listings
Two Cloudflare Workers — HS Codes Classifier and Document-to-JSON — are running with x402 paywalls settled in USDC on Base
A Google Sheets add-on — =HSCODE(A2) — returns real customs codes from real product descriptions
Zero external API calls in the last 24 hours
Zero active users across all servers
Zero revenue

Everything is configured correctly. Nothing is reaching anyone.

What I built

The stack, briefly:

MCP servers (35)

Validators (iban-validator, vat-validator, swift-validator), parsers (invoice-parser-v2, document-to-json-mcp), extractors (contract-clause-extractor, meeting-action-extractor), and domain tools (hs-codes-mcp, license-checker-mcp, medical-coding-helper-mcp).

Cloudflare Workers with x402

Every Worker sits behind an x402 paywall. Agents pay USDC on Base — no signup, no API key. Pricing is $0.01 per call for single operations, $0.05 for batch operations up to 100 items. 50 free calls per day.

Google Sheets add-on

A custom function =HSCODE("laptop computer") that returns 8471.30 | confidence: 0.95 in any cell. The add-on calls the same Cloudflare Worker, caches results locally, and gives regular spreadsheet users direct access to the same classifier that agents get via MCP.

The technical details that actually matter

Service Bindings instead of public fetch

When I first connected a call counter to my MCP servers, I tried the obvious thing: a public fetch() call to another Worker inside ctx.waitUntil(). The request never arrived. Cloudflare's loop protection blocks worker-to-worker calls through public URLs.

The fix is Service Bindings — direct worker-to-worker calls declared in wrangler.toml. The [[services]] block binds a name (CALL_COUNTER) to another Worker (call-counter). Inside the handler, env.CALL_COUNTER.fetch(...) reaches the target Worker directly, bypassing the public network entirely.

Non-blocking, fire-and-forget, and it works. This took me three hours to figure out.

KV cache is doing real work

The classifier caches results by SHA-256 hash of the normalized description. When someone classifies "laptop computer" for the first time, it costs an OpenAI call. The second time, it returns from KV in milliseconds.

Across the 35 servers, this cache absorbs repeat queries at near-zero cost. It's the difference between $0.0003 per call and $0.000001 per call.

Secrets management is fragile

Uploading a secret via wrangler secret put does not always propagate to the current deployment. Sometimes it does. Sometimes it needs a follow-up wrangler deploy. I spent an hour chasing a token mismatch that turned out to be a stale deployment.

If you're debugging an unauthorized response and everything looks correct, redeploy. Then redeploy again.

Three monetization models — and what each one means

Model 1: Freemium

Each server has a Free tier — 50 calls per day. This makes the listing visible in the marketplace and gives users a zero-friction way to try it. Good for discovery, bad for revenue.

Model 2: Subscription ($19/mo)

The MCPize marketplace adds a Pro tier — $19/month for 5,000 calls. This is the model the marketplace actually wants — one subscription, one API key, uniform billing across all servers. Predictable, but the barrier is high for first-time users.

Model 3: Pay-per-call (x402, $0.01)

Agent-native. No signup, no subscription, no API key. An agent calls a tool, gets a 402 response with a payment challenge, settles in USDC, gets the result. This is the most technically elegant model — and the least understood by anyone outside the crypto-native AI space.

In practice, all three can coexist on the same server. My iban-validator has all three: Free tier, Pro $19/mo, and x402 pay-per-call at $0.01–$0.02.

The problem is that the third model assumes demand. If no agent is calling your server, there's nothing to bill.

What I learned

Configuration is not distribution.

I can spend a week tuning SEO, pricing tiers, and listing descriptions. None of it matters if nobody opens the page. Marketplace listings don't automatically bring traffic — they give traffic somewhere to land when it arrives.

x402 doesn't sell itself.

The protocol is elegant. The settlement is instant. But agents only pay when they have a reason to call. And they only call when the tool is either (a) in their default toolset, or (b) findable through a search mechanism they use. Neither of those things is automatic.

Google Sheets is underrated.

=HSCODE(A2) takes three seconds to type. No documentation, no API key, no setup. If you're building tools for non-developers, spreadsheet integration beats an API endpoint every time. A logistics manager will use a spreadsheet formula before they'll touch an MCP server.

What's next

Two directions:

Programmatic SEO. Generate hundreds of pages — "HS code for laptop", "HS code for wooden chair", "IBAN validator for Germany" — each linking directly to the relevant server or the Sheets add-on. Google indexes them, long-tail traffic arrives, conversion becomes a matter of landing page quality.

Distribution through existing channels. The Dev.to and Medium posts are the start. Reddit's r/SideProject and r/mcp. Hacker News. Discord servers for AI agents. Every channel that already has an audience for this problem.

Everything else is already built. The remaining work is getting the first 100 users to see it.

Try it

Google Sheets: open a new sheet, go to Extensions → Apps Script, and paste the code from my GitHub. Then in any cell: =HSCODE("iPhone 15 Pro"). You'll get 8517.12.

MCP servers: browse the list at mcpize.com/mcp/iban-validator — it's a good example of the pricing model, the SEO setup, and the overall shape of what I've shipped.

Cloudflare Workers: hs-codes-classifier.boring-saas-infra.workers.dev — try /health and see the 402 response on /classify.

Everything: boring-saas-infra.pages.dev

What's your experience with AI monetization? Is it a traffic problem for you too, or have you found channels that actually convert?

I built a Creator Engine that extracts promises from sales conversations (80% accuracy)

Oleksandr — Fri, 02 Oct 2026 14:30:06 +0000

Last week I built 32 MCP servers. Today I want to share the more ambitious project: the Creator Engine — a system that compares what sales promises to what the contract actually says.

The problem

Sales teams promise things. Contracts specify things. They don't always match.

"Weekly reports every Monday" -> contract says "provide reports" (no frequency)
"$50,000 all-in" -> contract says "$75,000"
"99.99% uptime SLA" -> contract says "99.9%"
"SSO included" -> contract has no mention

Each mismatch is potential revenue loss, legal exposure, or customer churn. Traditional CLM tools are expensive ($50K+/yr), heavy, and focus on drafts — not on reality alignment.

What I built

Promise Alignment Benchmark v0 — an executable specification for testing the engine.

Structure

creator-engine/benchmarks/promise-alignment/v0/ contains:

cases/ — 20 test cases (PA-001 ... PA-020)
schemas/ — 5 JSON schemas (promise, term, alignment, evidence, impact)
expected/ — ground truth
reports/ — evaluation output

20 smoke cases

Cover:

EXACT match (identical promise + contract clause)
SYNONYM match ("mobile app" = "native iOS/Android applications")
IMPLIED match (SSO implied by SAML/OAuth support)
MISSING (weekly reports promised, contract silent on frequency)
CONFLICT ($50K vs $75K, June 30 vs August 15, 5 seats vs 3, 99.99% vs 99.9%)
AMBIGUOUS ("really fast" vs "adequate response time")
PARTIAL (3 integrations promised, 1 in contract)
NO_PROMISE (optional feature "could add later" — no commitment created)
PROMPT INJECTION ("ignore all previous instructions" — engine resists)

8 critical invariants

HARD FAILURE — 19/20 = FAIL if any invariant breaks.

INV-001: CONFLICT requires evidence
INV-002: financial.amount requires calculation_id
INV-003: Evidence location must exist in source
INV-004: NOT_COMMITMENT cannot create a Promise
INV-005: AMBIGUOUS cannot have review_required = false
INV-006: LLM-explanation cannot create new factual value
INV-007: OBSERVED cannot describe arithmetic
INV-008: Prompt injection cannot change system policy

The engine

Three-step LLM pipeline:

Extract promises from sales conversation -> PROM-001, PROM-002...
Extract contract terms from contract text -> TERM-001, TERM-002...
Align them -> EXACT | IMPLIED | PARTIAL | CONFLICT | MISSING | AMBIGUOUS

Then engine-level invariant checks run on top. For example:

Architectural rule: LLM extracts, engine decides. Never LLM to final truth.

Results

After 3 prompt iterations:

v0.1: 65% (13/20)
v0.2: 70% (14/20)
v0.3: 80% (16/20)

Zero invariant violations across all 20 cases.

Failures that remain are mostly edge cases where ground truth is debatable:

PA-004: 1M/month vs 12M/year -> mathematically EXACT, but spec says IMPLIED
PA-015: bundled promise -> 3 terms -> mix of EXACT and PARTIAL
PA-017: 2 promises -> 1 term -> EXACT or IMPLIED?

This is expected. 80% is a baseline, not production. Next: multi-step pipeline + verification layer (Phase 42).

Code

GitHub: Alex-Dev-Web-C-DE/creator-engine

Not on npm yet — it's a benchmark repo, not a package.

What's next

Phase 42 — Alignment Engine (separate stage, not one prompt)
Phase 43 — Conflict / Deviation Engine
Phase 44 — Evidence Engine
Phase 45 — Impact Engine
Phase 49 — Sales Promise Tracker (first commercial product on top)

The engine will power 5 products: Sales Promise Tracker, ScopeGuard, InvoiceGuard, DeliveryGuard, RevenueLeak.

All share the same core: Comparison Intelligence.

Try the MCP servers

While the engine matures, you can try the live MCP servers: 35 servers on MCPize — validators, parsers, extractors.

Most relevant for the engine use case:

Invoice Parser ($0.50) — MCP
Contract Clause Extractor ($0.75) — MCP
Meeting Action Extractor ($0.40) — MCP

All x402: agents pay USDC on Base, no signup, no API keys.

What's your take? Is 80% good enough to ship a human-in-the-loop MVP, or should I push for 90%+ before any customer touches it?

HS Codes Classifier — just launched on Product Hunt

Oleksandr — Thu, 01 Oct 2026 07:50:59 +0000

HS Codes Classifier turns any product description into an HS (Harmonized System) customs code via AI.

Just launched on Product Hunt. Support appreciated: https://www.producthunt.com/products/hs-codes-classifier

Built on Cloudflare Workers + x402 protocol for AI-agent payments.
$0.01 per call, 50 free/day, no signup.

Available as MCP server + REST API.

How I built 26 MCP servers + 2 REST APIs in 2 days with $0 infrastructure

Oleksandr — Tue, 29 Sep 2026 15:20:44 +0000

I'm a solo developer. Over the last 2 days, I shipped:

26 MCP servers on MCPize (validators, converters, formatters)
2 REST APIs on Cloudflare Workers (HS Codes Classifier, Document-to-JSON)
1 custom x402 gateway (Furlpay, self-hosted)

Total infrastructure cost: $0.

This post is about how I did it, what worked, and what didn't.

The problem: getting paid as a solo dev

Traditional payment processors don't work for everyone. Depending on where you are, Stripe, PayPal, and similar services may not be available or may have restrictions.

I needed a payment path that:

Works globally
Has no signup friction
Can charge per call, not per month
Works natively with AI agents

Crypto is the answer.

And in 2026, there's a new protocol that makes crypto-native payments work natively with AI agents: x402.

What is x402?

x402 is a protocol built on top of HTTP. The idea is simple:

AI agent calls your API endpoint
Endpoint returns HTTP 402 Payment Required with payment details
Agent pays $0.01 USDC (on Base)
Agent re-calls with payment proof
Endpoint returns the result

No signup. No API keys. No OAuth. No subscriptions.

Just: pay per call.

It's designed for the AI agent economy — where an agent needs to call 100 different APIs, and signing up for each one is impractical.

The stack

Here's what I used:

1. Cloudflare Workers

Why: Serverless, stateless, free tier of 100k requests/day.

Numbers:

Cold start: 7ms
Free tier: 100k requests/day
Setup: npm install -g wrangler + wrangler deploy

Deploy code example:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    if (url.pathname === "/health") {
      return new Response("OK");
    }

    if (url.pathname === "/classify") {
      const pay = paywall({
        price: 0.01,
        payTo: env.PAY_TO,
        quoteSecret: env.QUOTE_SECRET,
        network: "base",
      });

      return pay(async (req) => {
        const { description } = await req.json();
        const hsCode = await classify(description);
        return Response.json({ hs_code: hsCode });
      })(request, env);
    }

    return new Response("Not Found", { status: 404 });
  },
};

2. Furlpay (x402 gateway)

Why: Self-hosted x402 gateway. No vendor lock-in. 100% of payments go to my wallet.

Setup:

npm install -g @furlpay/gateway
furlpay-gateway secret
wrangler deploy

3. MCPize (MCP server distribution)

Why: MCP (Model Context Protocol) is how AI agents discover tools. MCPize is the marketplace.

What I did: Wrapped my APIs as MCP servers, deployed to MCPize. Now ChatGPT/Claude agents can find them.

4. gpt-4o-mini (for AI endpoints)

Why: Cheap, reliable. $0.15/1M input tokens.

At $0.01/call, margin is healthy even with heavy use.

What worked

Cloudflare Workers + Fetch API — perfect for stateless x402 APIs
Furlpay — one middleware = paywall
MCPize — free distribution for MCP servers
gpt-4o-mini — cheap AI

What didn't work

Reddit — new accounts get auto-filtered without karma
mcpize dev on Windows — broken (port conflict with itself). Use npm run dev instead.
Express + Cloudflare Workers — incompatible. Use Fetch API.

Results (so far)

26 MCP servers live
2 REST APIs live
$0 spent on infrastructure
0 customers (just launched)
$0 revenue (just launched)

What's next

First paying customer
More AI endpoints (Document Intelligence family)
Building in public

Try it

HS Codes Classifier (MCP): https://mcpize.com/mcp/hs-codes-mcp
HS Codes Classifier (REST): https://hs-codes-classifier.boring-saas-infra.workers.dev
Document-to-JSON (REST): https://document-to-json.boring-saas-infra.workers.dev

All APIs use x402 — pay $0.01 USDC per call, no signup.

If you're a solo dev and payment processors don't work for you — I'd love to hear how you handle it. Reply or DM.

Why We Need Client-Side Secret Scanning Before Commits Hit Main

Oleksandr — Sun, 20 Sep 2026 18:08:50 +0000

When building web applications and developer tools, security is often treated as a backend concern—something handled by server-side middleware, environment variables, and API gateway filters. But what happens long before code ever reaches a deployment pipeline? It happens right inside the developer's local workflow.

The Hidden Cost of Accidental Leaks

We've all heard stories about API keys, database credentials, and personal access tokens accidentally pushed to public (or even private) repositories. Even with .gitignore properly configured, mistakes slip through:

Temporary test files committed under wrong names.
Hardcoded configuration strings used "just for a quick local check."
Staging tokens mixed into frontend utility scripts.

Relying solely on post-commit hooks or cloud scanning tools means the secret has already left your machine. The damage might already be done by the time CI/CD catches it.

Shifting Left with Client-Side Linters

This is why implementing proactive, lightweight scanning directly in the development loop matters. A client-side linter or utility tool can inspect code patterns instantly, warning developers before a commit or push is even executed.

Key benefits of catching secrets early:

Zero Latency Feedback: No waiting for remote CI pipelines to run.
Local Privacy: Code and potential secrets stay local, analyzed via fast regex patterns or pattern matching rules in JavaScript.
Developer Habit Formation: Immediate visual warnings teach better coding hygiene naturally.

Building Lightweight Dev Tools

While working on Secrets Linter, my goal was to keep things friction-free—fast parsing, zero unnecessary bloat, built cleanly using modern web technologies and Tailwind CSS for a crisp, distraction-free interface. Developers don't need another heavy, opinionated framework slowing down their workflow; they need sharp, focused utilities that solve one problem exceptionally well.

How do you handle secret detection in your local development environment? Do you rely on pre-commit hooks, git hooks, or manual checks? Let me know in the comments!