Forem: Tool Mango

I dropped my SaaS Pro tier from $19 to $9 in 24 hours. Here's why.

Tool Mango — Thu, 07 May 2026 14:14:04 +0000

TL;DR

I shipped Pro at $19/mo, looked at it 24 hours later, dropped it to $9/mo, and felt instantly more honest about my product. Here's what changed about my pricing thinking — and the framework I use now.

What I shipped first

I built ToolMango — an AI tool directory with a Stack Builder that recommends a custom tool stack based on your project description. Pro tier was supposed to add: save stacks, label them, history dashboard, PDF export, email-the-stack, priority API queue, agency white-label, team workspace.

I priced it at $19/mo because that's the SaaS-indie default. It's where every other "AI thing" starts. ChatGPT is $20. Cursor is $20. Notion AI is $10. So $19 felt right.

But here's what I actually shipped on day 1:

Pro features that worked:

Save stacks (dashboard list)
Stack history (list all your stacks)

Pro features I "promised" on the pricing page:

PDF export (not built)
Email-the-stack (not built)
Priority API queue (just marketing copy)
Agency white-label (months away)
Team workspace (months away)

The honest competitive comparison:

Product	$/mo	What you get
ChatGPT Plus	$20	Frontier AI you'd use daily
Cursor	$20	Replaces a junior engineer
Notion AI	$10	AI inside an entire workspace
Buffer	$6	Multi-account social scheduler
Carrd Pro	$19/yr	Entire website builder
My ToolMango Pro at launch	$19/mo	Save 5 stacks + history

I was charging like Cursor and ChatGPT but delivering "saved bookmarks." Anyone who paid $19 and saw what they got would feel cheated within a week, then leave a bad review. That's the fastest way to kill a new product.

Why I dropped to $9

Three reasons, in order of importance:

1. Honest pricing reflects what you've actually built

I was anchoring Pro to the promise of features (PDF, email, white-label, priority) rather than the delivery of features (save + history). That's bait-and-switch by another name.

Pricing should reflect what a customer can use the day they pay. Roadmap features are the reason someone might pay later when they ship — not the reason to charge more now.

2. $19 was a credibility leak

In SaaS pricing, you anchor against what the user has bought before. They've bought ChatGPT at $20. They've bought Notion AI at $10. They know what those products feel like.

If I show up at $19 with "save your stacks," they don't compare me to "save your stacks at $25." They compare me to "ChatGPT at $20." And lose.

At $9, the comparison flips. They compare me to "Buffer at $6" and "Carrd at $19/yr." Now I look reasonable. The exact same product is positioned completely differently.

3. Lower price compounds via word-of-mouth

The single biggest source of indie SaaS growth at our scale is "my friend mentioned this tool." For that to happen, the price has to be at "I just signed up, you should too" levels — sub-$10/mo.

At $19, the conversation is "is this worth $19?" At $9, the conversation is "this is cool, you should try it." The first is a sales conversation. The second is word-of-mouth. The second compounds.

The pricing ladder I committed to publicly

Today:        $9   saves + history + labels
+PDF export:  $12  real deliverable utility
+email send:  $14  workflow automation
+team/agency: $29  Agency tier; existing Pro stays $14

Anyone who signed up at $9 today is grandfathered at $9 forever, even when prices rise. That solves two problems:

Loyalty signal — early adopters get rewarded
No price-cap on revenue — new signups pay current price

Existing customers don't churn on price increases (because they're not affected), and new customers pay what the product is now worth.

Pricing framework I use now

The four questions I ask before setting a price:

Q1: What can the customer use the day they pay?

Not what's on the roadmap. What works. List those features only. Stop counting roadmap features.

Q2: What does this anchor against in the user's mental model?

If they're thinking "this is like Notion AI, $10," start within 50% of that. If they're thinking "this is like a $200 enterprise tool," start higher. The user's frame matters more than your competitive analysis spreadsheet.

Q3: At this price, would I recommend it to a friend?

If I'm hesitating, it's too expensive. The friend recommendation is the marketing channel. Price has to enable it.

Q4: How does the price scale with what I ship next?

If price stays the same forever, I never get to capture the value of what I'll ship later. If price rises with features, early adopters churn.

The answer is rising tiers + grandfathering. Each new feature ships with a small price bump for new signups. Existing signups stay at their original price. Both groups feel like they're getting a deal.

The math of grandfathering

Counter-intuitively, grandfathering early customers at lower prices is more profitable than not.

Without grandfathering:

Sign up early adopter at $9
Raise to $14 in 3 months
Early adopter churns at month 3 because "the value isn't worth $14"
You lose them forever

With grandfathering:

Sign up early adopter at $9
Raise to $14 for new customers in 3 months
Early adopter stays at $9 forever, becomes a happy reference customer
New customer pays $14, anchored against what current $9 customers experience

LTV is much higher in the grandfathered version. And early adopters become your evangelists — they share screenshots of "I'm only paying $9, the new price is $14" which is basically free marketing.

What I changed in code

Three small updates:

Stripe Price: Created a new $9/mo Price in the same Product. Old $19 Price archived (still works for any test customers who already subscribed at $19).
/pricing page: Updated copy. Listed only delivered features. Moved roadmap items to a clearly separated "On the roadmap" block with the disclosure that they're not yet built.
Dashboard upgrade CTA: Updated to mention the $9 founder rate and grandfathering.

Total change: ~50 lines of code, including the dashboard.

The deeper lesson

Indie SaaS pricing is over-influenced by the "what should I charge?" question and under-influenced by the "what can I deliver?" question. The two need to match.

If they're out of sync, the customers either feel ripped off (too high relative to delivery) or you leave money on the table (too low relative to delivery). The fix is honest scoping: what works today, what's the closest competitive anchor, and where can the price grow as the product grows.

I now think of pricing as a curve, not a number. The number changes as the curve moves. Customers grandfather on the curve they signed up at. Both sides win.

The site

If you want to see what $9/mo Pro looks like in the wild: ToolMango is the planner. /pricing shows the new positioning. /about explains the editorial ROI methodology.

Roast the pricing in the comments — that's what dev.to is for.

I cut my AWS bill by 93% by ditching Fargate for a single Lightsail VM

Tool Mango — Tue, 05 May 2026 21:51:22 +0000

TL;DR

I built ToolMango, an AI tools directory, on AWS Fargate. The bill came back at $345/mo before traffic. I migrated to a single $12 Lightsail VM in an afternoon and cut costs by 93% while keeping the same Next.js + Postgres + Redis + BullMQ stack alive.

Here's exactly what I changed, what broke, and what I'd do differently.

What ToolMango is (so the cost numbers make sense)

ToolMango is an editorial directory of AI tools. It scores tools on an ROI Score (cost, time-to-value, output quality, free-tier generosity, category fit, reader engagement) and ranks them — before knowing whether the tool has an affiliate program. Tools we don't earn from frequently outrank tools we do.

Tech stack:

Next.js 14 App Router
Postgres 16
Redis (BullMQ for the agent job queue)
Anthropic Claude Sonnet for editorial agents (research, SEO sweep, social drafts)
A worker process running 5 cron schedules

Pre-revenue. Brand new domain. ~106 tools indexed at the time of writing.

The original Fargate setup

I started on AWS because I had CDK boilerplate from another project. The architecture was over-engineered for a directory site getting zero traffic:

CloudFront → ALB → Fargate (web ×2 tasks, worker ×1)
                ↓
          Aurora Serverless v2 (writer)
          ElastiCache (Redis, t4g.small ×2)
          NAT ×2 (multi-AZ)
          VPC + interface endpoints
          WAF (managed rule sets)

The CDK code is clean. It deploys with one command. It autoscales. It survives an AZ failure. It's exactly what a series-A SaaS would run.

It's also $345/mo for zero users.

What was actually costing money

I broke it down with aws ce get-cost-and-usage and a few aws ecs describe-task-definition calls:

Resource	$/mo
Aurora Serverless v2 (no auto-pause, 0.5 ACU min)	$86
Fargate ARM64 (3 tasks: 2× web at 1vCPU/2GB + 1× worker at 0.5/1GB)	$71
2× NAT Gateways (multi-AZ)	$65
VPC interface endpoints (Secrets Manager × 3 AZ + others)	$40
ALB + WAF	$34
CloudWatch + Container Insights	$15
Public IPv4 charges	$15
ElastiCache (cache.t4g.small ×2 nodes)	$11
Misc (CloudFront, Secrets, Route53, S3)	$8

The killer insight: about $87/mo of that bill is "infrastructure plumbing" — NAT, ALB, ElastiCache, VPC endpoints. None of it is doing real work for the application. It's all there to support the architecture itself.

That's the floor on a Fargate setup. For a pre-revenue project, it's nuts.

Phase 1: Skeleton mode on AWS

Before migrating, I tried to make Fargate cheap. CDK changes I shipped:

// Aurora: enable auto-pause when idle
const cfnCluster = cluster.node.defaultChild as rds.CfnDBCluster;
cfnCluster.serverlessV2ScalingConfiguration = {
  minCapacity: 0,        // was 0.5 — auto-pause after 5 min idle
  maxCapacity: 2,        // was 4
  secondsUntilAutoPause: 300,
};

// Network: 1 NAT instead of 2
natGateways: 1,           // was 2 (multi-AZ)

// Web: smaller, fewer tasks, autoscale up if needed
desiredCount: 1,          // was 2
cpu: 512,                 // was 1024
memoryLimitMiB: 1024,     // was 2048

// Worker on Fargate Spot
capacityProviderStrategies: [
  { capacityProvider: "FARGATE_SPOT", weight: 4 },
  { capacityProvider: "FARGATE", weight: 1 },
],

// Container Insights off
containerInsightsV2: ecs.ContainerInsights.DISABLED,

// Backup retention
backup: { retention: cdk.Duration.days(1) },  // was 14

// WAF: removed entirely (CloudFront has free Shield Standard)

Result: $345/mo → ~$140/mo. Better, but still ridiculous for a pre-revenue project.

The reason it stopped at $140: NAT, ALB, ElastiCache, VPC endpoints, and Aurora storage all have hard floors. You can't make Fargate genuinely cheap because the architecture itself isn't designed for cheap.

Phase 2: The honest migration

Lightsail is AWS's "give me a Linux VM and stop overthinking it" tier. $12/mo for 2 vCPU, 2GB RAM, 60GB SSD, 3TB transfer — and it includes a static IP and a firewall.

The plan: run everything on one VM in Docker Compose.

services:
  postgres:
    image: postgres:16-alpine
    volumes: [./data/postgres:/var/lib/postgresql/data]
    deploy: { resources: { limits: { memory: 512M } } }

  redis:
    image: redis:7-alpine
    command: redis-server --appendonly yes --maxmemory 128mb --maxmemory-policy noeviction
    volumes: [./data/redis:/data]
    deploy: { resources: { limits: { memory: 192M } } }

  web:
    image: tm-web:latest
    ports: ["127.0.0.1:3000:3000"]
    env_file: .env
    depends_on:
      postgres: { condition: service_healthy }
      redis: { condition: service_healthy }
    deploy: { resources: { limits: { memory: 768M } } }

  worker:
    image: tm-worker:latest
    env_file: .env
    depends_on:
      postgres: { condition: service_healthy }
      redis: { condition: service_healthy }
    deploy: { resources: { limits: { memory: 384M } } }

For HTTPS termination: Caddy, which auto-issues Let's Encrypt certs on first request. Configuration is one stanza:

toolmango.com, www.toolmango.com {
    reverse_proxy 127.0.0.1:3000
    encode gzip zstd
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
    }
}

Caddy reloads, Caddy gets the cert. Total setup time: 30 seconds.

Migrating Aurora data to local Postgres

Aurora is in a private subnet (PRIVATE_ISOLATED), so I couldn't pg_dump from outside. The workaround: spin up a one-off ECS Fargate task in the existing Web's VPC that runs pg_dump and uploads to S3.

aws ecs run-task \
  --cluster tm-prod-compute \
  --task-definition tm-prod-pgdump \
  --launch-type FARGATE \
  --network-configuration 'awsvpcConfiguration={subnets=[subnet-...],securityGroups=[sg-...],assignPublicIp=DISABLED}'

The task definition uses postgres:16-alpine, installs aws-cli on the fly, runs:

pg_dump --no-owner --no-acl --clean --if-exists -h $DB_HOST -U $DB_USER -d toolmango \
  | gzip > /tmp/dump.sql.gz \
  && aws s3 cp /tmp/dump.sql.gz s3://tm-prod-assets/migration/dump.sql.gz

On the Lightsail VM, pull from S3 (via a presigned URL since Lightsail VMs don't have IAM roles by default), gunzip, and pipe into the local Postgres container:

gunzip -c /tmp/dump.sql.gz | docker compose exec -T postgres psql -U tmadmin -d toolmango

64 published tools transferred cleanly. ~485KB of data total (it's a directory site — barely any data).

Building images on the VM

Lightsail is x86_64. Fargate was ARM64. So I had to rebuild for x86 anyway, which is a perfect excuse to build directly on the VM and skip the registry-push dance:

docker build --network=host -f Dockerfile.web -t tm-web:latest \
  --build-arg NEXT_PUBLIC_SITE_URL=https://toolmango.com \
  --build-arg NEXT_PUBLIC_PLAUSIBLE_DOMAIN=toolmango.com \
  .

Next.js builds need ~1.5-2GB peak memory. Lightsail's "small_3_0" has 2GB RAM. Tight, but adding 2GB swap solved it:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile
echo "/swapfile none swap sw 0 0" | sudo tee -a /etc/fstab

First build: ~6 min. Subsequent builds with Docker layer cache: ~2 min. Acceptable.

Tearing down AWS Fargate

After Lightsail was serving traffic, I tore down the Fargate stacks via CDK:

# Take final Aurora snapshot first (safety rollback)
aws rds create-db-cluster-snapshot --db-cluster-identifier ... --db-cluster-snapshot-identifier tm-prod-final-...

# Disable deletion protection
aws rds modify-db-cluster --no-deletion-protection ...

# Delete Aurora cluster + writer
aws rds delete-db-instance --skip-final-snapshot ...
aws rds delete-db-cluster --skip-final-snapshot ...

# CDK destroy stacks in reverse dependency order
cdk destroy tm-prod-edge --force      # CloudFront, WAF
cdk destroy tm-prod-compute --force   # Fargate, ALB, ECS cluster
cdk destroy tm-prod-data --force      # ElastiCache (S3 retains via RemovalPolicy.RETAIN)
cdk destroy tm-prod-network --force   # VPC, NAT, subnets

CloudFront's destroy is the slowest — disabling a distribution then deleting it takes 15-20 min. Aurora delete is 5-10 min. Compute and network are 3-5 min each.

Total teardown: ~30-40 min unattended.

Auto-deploy via GitHub Actions

The piece that ties it all together: a workflow that on push to main rsyncs the source, rebuilds images on the VM, runs Prisma migrations, restarts containers:

- name: Rsync source to Lightsail
  run: |
    rsync -az --delete --exclude='node_modules' --exclude='.next' --exclude='.git' \
      -e "ssh -i ~/.ssh/id_ed25519" \
      ./ ${{ secrets.LIGHTSAIL_USER }}@${{ secrets.LIGHTSAIL_HOST }}:/home/ubuntu/toolmango/src/

- name: Build images on Lightsail
  run: |
    ssh ... 'cd /home/ubuntu/toolmango/src && \
      sg docker -c "docker build -f Dockerfile.web -t tm-web:latest ." && \
      sg docker -c "docker build -f Dockerfile.worker -t tm-worker:latest ."'

- name: Run prisma migrate + restart services
  run: |
    ssh ... 'cd /home/ubuntu/toolmango && \
      sg docker -c "docker compose run --rm --no-deps web npx prisma migrate deploy" && \
      sg docker -c "docker compose up -d --force-recreate web worker"'

- name: Smoke test
  run: |
    for i in {1..6}; do
      [ "$(curl -s -o /dev/null -w '%{http_code}' https://toolmango.com/api/healthz)" = "200" ] && exit 0
      sleep 5
    done
    exit 1

First successful auto-deploy: 3m50s end-to-end. From git push to verified 200 OK from Caddy.

What it costs now

Resource	$/mo
Lightsail small_3_0 (2 vCPU, 2 GB RAM, 60 GB SSD, 3 TB transfer)	$12
S3 (assets bucket — kept)	$1
Route53 (zone + queries)	$1
Secrets Manager (kept for credentials backup, ~10 secrets)	$4
Anthropic API (Claude Sonnet for editorial agents)	$5–15
Total	~$23–33

That's a 93% cut from $345/mo. Same site, same functionality, same automation pipeline. The site is at https://toolmango.com if you want to verify it's actually working.

What I gave up

Honest list of what's worse on Lightsail:

No multi-AZ HA. Single VM = single point of failure. AZ-level outage means downtime.
No Aurora point-in-time restore. Just nightly pg_dump to S3. RPO is up to 24h. Acceptable for a content site, not for transactional data.
No autoscaling. Vertical only — bump to a bigger Lightsail bundle if traffic grows. The next tier is $24/mo for 4GB / 80GB. Past that, $44/mo for 8GB. At those numbers you should rethink Lightsail vs going back to managed services.
Manual ops. No service auto-restart on host failure. If the VM dies, I get notified by uptime monitor and SSH in. That's the trade.

What I'd do differently

Skip Fargate entirely for pre-revenue projects. Start on Lightsail. The migration was 4 hours; if I'd started there, that's 4 hours and ~$700 of avoided bills (the 6 days I was on Fargate).
Don't enable Container Insights "just because." It's $5-15/mo and you'll never look at it on a small project.
Don't let CDK enable WAF by default. WAF is real money ($12-15/mo) for a pre-revenue site that's not under attack. CloudFront's free Shield Standard is enough.
Don't pre-provision multi-AZ NAT. Single NAT is fine until you have customers.
Use Aurora minCapacity: 0 from day 1. The auto-pause feature added in 2024 makes Aurora Serverless v2 actually serverless. Most CDK examples still default to 0.5.

When to migrate back to Fargate

The CDK code is still in the repo. cdk deploy --all brings the production-grade Fargate stack back up; restore the latest Lightsail backup to a fresh Aurora cluster; cutover DNS.

I'll do that when any of these hits:

Sustained traffic > 200 req/sec (single VM saturates)
Need for multi-AZ HA (revenue at risk from single AZ outage)
DB > 20 GB (Postgres on local SSD becomes risky for backup/recovery)
Compliance requirement (SOC 2 etc.)

Until then, $25/mo. The CDK code waits patiently.

The site

If you want to look at what this stack actually serves: ToolMango. The methodology behind the editorial ROI score is at /about, the affiliate disclosure is at /disclosure.

The writeup of the migration is in docs/lightsail-migration.md in the repo if you want the step-by-step. Happy to answer questions in the comments.

If you found this useful and you've done a similar AWS-to-cheap-VM migration, I'd love to hear what you cut and what burned.