Not throttled. Not rate-limited. Banned. Error 1010, "the owner of this website has banned your access based on your browser's signature." From a transactional email API I had been paying for. From the same machine I had been using all week.

This is the story of the next 30 minutes, what I rebuilt with Listmonk + AWS SES, and the exact commands so you do not lose half a day if it happens to you.

what actually happened

I run a small revenue stack on yanmiayn.com. Three emails that morning: one welcome, one receipt, one reply notification.

Around 09:14 KST the Resend dashboard stopped loading. Not a 500. The Cloudflare interstitial:

Error 1010
Access denied
The owner of this website has banned your access
based on your browser's signature.

api.resend.com returned the same. So did the docs. So did the status page.

curl -I https://api.resend.com/emails
# HTTP/2 403
# server: cloudflare
# cf-mitigated: challenge

LTE worked. So Cloudflare had fingerprinted my IP+TLS and decided I was a bot. Paying customer, no scrapers, no abuse. Locked out anyway.

the debugging spiral

1. Support ticket. Email-only. 24-48 hour reply window. My signup flow is already broken.
2. Resend status page green. Of course green. The ban is on me, not them.
3. Rotated home IP. Same 1010.
4. Residential proxy got past 1010, hit a different captcha. Gave up.

The vendor and the gatekeeper are the same company. There is no appeal at startup speed.

I gave myself 30 minutes.

why Listmonk + AWS SES

• I own the sending reputation.
• Runs on the box I already have.
• Both transactional and bulk in one stack.
• Deliverability not worse than Resend.
• Bill stays low.

Listmonk is an open source Go binary with an HTTP transactional API and a campaigns UI. AWS SES is the boring SMTP relay underneath at ~$0.10 per 1,000 emails.

the 30-minute migration

minute 0-5: SES domain identity

aws configure
aws ses verify-domain-identity --domain yanmiayn.com --region us-east-1
aws ses verify-domain-dkim --domain yanmiayn.com --region us-east-1

DNS:

token1._domainkey.yanmiayn.com  CNAME  token1.dkim.amazonses.com
token2._domainkey.yanmiayn.com  CNAME  token2.dkim.amazonses.com
token3._domainkey.yanmiayn.com  CNAME  token3.dkim.amazonses.com

yanmiayn.com           TXT  "v=spf1 include:amazonses.com ~all"
_dmarc.yanmiayn.com    TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yanmiayn.com; fo=1"

Start with p=quarantine. Move to p=reject after a clean week.

minute 5-8: SES SMTP credentials

aws iam create-user --user-name ses-smtp-listmonk

cat > ses-send-policy.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ses:SendRawEmail", "ses:SendEmail"],
      "Resource": "*"
    }
  ]
}
EOF

aws iam put-user-policy \
  --user-name ses-smtp-listmonk \
  --policy-name SesSendOnly \
  --policy-document file://ses-send-policy.json

Use the SES console "Create SMTP credentials" button to derive the SMTP username/password from the IAM access key.

minute 8-18: Listmonk on Docker

services:
  app:
    image: listmonk/listmonk:latest
    container_name: listmonk_app
    restart: unless-stopped
    ports:
      - "127.0.0.1:9000:9000"
    environment:
      LISTMONK_app__address: "0.0.0.0:9000"
      LISTMONK_db__host: db
      LISTMONK_db__port: 5432
      LISTMONK_db__user: listmonk
      LISTMONK_db__password: ${DB_PASSWORD}
      LISTMONK_db__database: listmonk
      LISTMONK_db__ssl_mode: disable
      LISTMONK_ADMIN_USER: admin
      LISTMONK_ADMIN_PASSWORD: ${ADMIN_PASSWORD}
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    container_name: listmonk_db
    restart: unless-stopped
    environment:
      POSTGRES_USER: listmonk
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: listmonk
    volumes:
      - ./pgdata:/var/lib/postgresql/data

cat > .env <<EOF
DB_PASSWORD=$(openssl rand -hex 24)
ADMIN_PASSWORD=$(openssl rand -hex 16)
EOF
chmod 600 .env

docker compose up -d db
sleep 5
docker compose run --rm app ./listmonk --install --yes
docker compose up -d app

Reverse-proxy with Caddy:

listmonk.yanmiayn.com {
    reverse_proxy 127.0.0.1:9000
}

minute 18-24: SES into Listmonk

Settings -> SMTP -> Add new:

Host:     email-smtp.us-east-1.amazonaws.com
Port:     587
Auth:     login
Username: <SES SMTP username>
Password: <SES SMTP password>
TLS:      STARTTLS

Send a test. Check headers for dkim=pass and spf=pass.

minute 24-30: swap the transactional API

curl -X POST https://listmonk.yanmiayn.com/api/tx \
  -u "admin:$ADMIN_PASSWORD" \
  -H "Content-Type: application/json" \
  -d '{
    "subscriber_email": "u@example.com",
    "template_id": 3,
    "data": {"name": "Joon"},
    "content_type": "html"
  }'

Templates use Go syntax: {{ .Subscriber.Email }}, {{ .Tx.Data.name }}.

SES sandbox escape

New SES accounts: 200/day to verified addresses only. To go production: real website, specific description ("transactional only: receipts, password resets, signup confirmations"), honest volume, working unsubscribe. Approved in 14 hours for me.

Until then:

aws ses verify-email-identity --email-address you@yanmiayn.com --region us-east-1

what I gave up

• Bounce/complaint handling. With SES you wire SNS -> Listmonk webhook yourself.
• Polished dashboard. Listmonk's UI is functional.
• Edge POPs. SES has regions. For most senders this does not matter.

what I gained

• No vendor can lock me out of my own domain.
• Bill from $20/mo to ~$1/mo at my volume.
• Same stack handles 50k campaign sends and signup receipts.

the takeaway

If you build on a transactional email API, write down a 30-minute migration plan today, before you need it. Park the Listmonk subdomain, the SES domain identity, and DNS records now. Keep the compose file in your infra repo.

Resend is fine. SendGrid is fine. Postmark is fine. They are all also one WAF rule away from being unavailable to you specifically. Owning the sender is small one-time work and real optionality.

If this saved you 4 hours, follow @yanmiayn for more boring infra escape hatches. Full runbook with SNS bounce wiring and a Node client wrapper at yanmiayn.com/cold-outreach-stack ($29, one-time).

Recently the topic of "Mike: open-source legal AI" has been gaining attention among indie developers. Here is a practical workflow for tackling it with Claude.

1. Frame the problem clearly

Claude works best when you give it a tight scope, sample inputs, and the success criterion. Skip the wall of text — describe the smallest reproducible task.

2. Use a prompt template

Reusable prompts are the difference between a one-off chat and a production system. A good template covers: role, context, constraints, examples, and an output contract.

3. Iterate with diffs, not rewrites

Ask Claude for a unified diff. It cuts token cost and makes review easier.

4. Cache the system prompt

For any SaaS feature using Claude, prompt caching turns a 4000-token system prompt into a near-free repeat call. Worth a 10-line refactor.

5. Wrap it in a tiny eval

Five hand-graded examples beat zero. Run them on every prompt change.

If you want a head start, I put together 100 production-ready Claude prompts for SaaS builders (auth flows, billing logic, CRUD scaffolds, error handlers, etc.). It is a one-time $7.50 PDF: https://payhip.com/b/bXtWi

Why this matters: any single LLM can hallucinate or have blind spots. When 11 models agree, signal-to-noise jumps. When they disagree, the disagreement itself is information.

The synthesized consensus

TypeScript vs JavaScript Recommendation

Consensus Recommendation

Start with JavaScript for your side project, but consider migrating to TypeScript as the project grows.

All three models agree that project size and complexity should be the primary deciding factor. For small, experimental, or throwaway projects, JavaScript's simplicity and faster iteration speed make it ideal for side projects where you're often exploring ideas quickly.

Key Considerations

When to stick with JavaScript (2/3 models strongly agree):

• Small scope or experimental projects
• Quick prototypes you'll build and potentially discard
• Projects where you're still exploring the problem space

When to use TypeScript (2/3 models strongly agree):

• Projects likely to grow beyond a few files
• Code you plan to maintain long-term
• Complex applications that will evolve over time

Decision Framework

Use this decision tree:

1. Small/quick side project? → Use JavaScript
2. Planning to maintain/expand it long-term? → Start with TypeScript
3. Uncertain about complexity? → Start with JavaScript and consider migrating key components to TypeScript later

Actionable Strategy

• JavaScript-first approach: Begin quickly, then migrate core components to TypeScript as complexity grows
• TypeScript-first approach: If you're committed to long-term maintenance or the project scope is inherently complex

Model Agreement/Disagreement

Agreed: All models Divergence: The models differ on default recommendation - Nemotron-3 and Mistral favor TypeScript earlier, while Llama-4 suggests starting with whichever you know better

Key Insight

The strongest signal is that project scope and maintenance intentions should drive your choice. All models agree that TypeScript provides long-term benefits for maintainability and bug prevention, but the overhead may not be worth it for simple side projects you want to explore quickly.

Start with JavaScript for rapid prototyping, but be prepared to migrate to TypeScript as your project grows in scope.

What each model said

Try it yourself

The full interactive arena page (with all 11 raw responses, confidence score, and timing data) lives here:

Canonical link: https://api.yanmiayn.com/arena/f2d29b00fffa

It's free, no signup, 10 questions/day per IP. Models rotate based on availability — typical run uses Llama 4, Mistral 675B, Qwen 3.5 397B, Qwen3-Coder 480B, Llama 3.1 405B, Nemotron Ultra 253B, GLM-5.1, DeepSeek V4 Pro, Kimi K2.5, MiniMax M2.7, and Phi-4.

Why publish on Hashnode?

I'm building Consensus Engine in public. If you want to follow along — including the open-source python SDK at github.com/MICONNM/consensus-engine-py — subscribe to this blog. New post every 2 days, each one a real decision dissected by 11 AIs.

This article was generated automatically from the arena run linked above. The code that generated it is open-source: see tools/hashnode_publisher.py in the OpenClaw workspace.