Most SaaS bills are too high because nobody questioned a single line on them. Mine is small because I questioned every line — and refused most of them.
Where the money goes — and where I refused to spend it.
In Part 1 I told you my monthly tech bill is about $125 — roughly a flat white a day. This piece is where the receipts come out.
The $125 splits into two products. The customer-facing platform that 360 users log into runs for $49 a month. The engine doing the heavy lifting in the background — backups, exports, scheduled jobs — runs for $76 a month. Both bills sit on the same AWS account.
The $49 customer-facing stack
What 360 users hit when they open the product:
- $19 — Fargate web container. A single container running the Next.js app and the in-process background workers. 1 GB of RAM, half a CPU. It serves the whole product.
- $18 — Load balancer. Terminates HTTPS, routes traffic, deals with TLS certificates. Yes, the load balancer costs about the same as the application server. That’s just what AWS charges — and it’s still cheaper than the alternatives.
- $9 — Admin Fargate container. A second container, smaller, running the internal admin dashboard. Off-limits to customers, on a separate subdomain.
- $9 — Staging Fargate container. A third container for staging. Off by default; on when I need to test something tricky.
- $4 — CloudWatch + ECR + S3 + the long tail. Logs, container image registry, small metadata storage.
Total: $49 a month. Web hosting, background jobs, three environments, log aggregation, container delivery — everything for a product with 360 users.
The $76 engine underneath
The backup engine is a different shape — pay-per-use Lambda instead of always-on containers, because the work is bursty.
The bill last March was $284 a month. Today it’s $76. Same product, same customers, no rewrite — I just paid attention.
The fix was three boring changes: streaming instead of buffering, arm64 Graviton instead of x86, and right-sizing memory from 4 GB defaults down to what each function actually needed.
Two weeks of work, 73% off the bill, about $2,500 a year saved. Paid for itself before it shipped.
What I deliberately didn’t buy
The bill is small because of what’s not on it. Here’s what a “standard” SaaS stack would have added, and what each refusal cost me to live without:
- No Datadog or New Relic. CloudWatch is included, and “good enough” beats a $40-a-month dashboard I’d check once a week.
- No Sentry. Application errors go to CloudWatch with severity tags. The query that finds them is six lines of CloudWatch Insights.
- No managed Redis. pg-boss runs queues inside Postgres. One fewer service to monitor, one fewer thing to back up.
- No Kubernetes or EKS. ECS Fargate runs containers without me babysitting a cluster. Saves the cluster fee and the engineer who’d otherwise be tuning it.
- No second auth provider. Supabase ships auth. Adding Auth0 on top would be paying for the same problem twice.
That’s roughly $150 a month of services I deliberately don’t subscribe to. Coffee-budget software isn’t an accident — it’s a refusal posture.
Things that aren’t on the AWS bill
A few specialist suppliers earn their place on the spreadsheet anyway:
- Supabase Pro — $25 a month. Database, authentication, row-level security, daily backups — all in.
- Postmark — ~$10 a month. Transactional email that actually lands in the inbox.
- Stripe — variable. Card fees scale with revenue, not with my decisions. Different category of cost.
- OpenRouter / Bedrock — capped. LLM spend is hard-limited to $5 per customer per day, enforced before the call goes out.
What this proves about the goals
Back to the four questions from Part 1.
Coffee-budget infra: every line item is inspectable. Each one is either fixed or pay-per-use, and the largest variable cost (LLM) has hard caps. The bill cannot quietly run away.
One operator plus AI: every tool on the list is something Claude and Codex have years of public documentation to work with. No exotic vendor with thin training data.
Zero management overhead: the refusal list above is the same as the “things I’d otherwise have to keep running on a Tuesday afternoon” list.
Velocity: fewer services means fewer dashboards, fewer logins, fewer surprises. The stack stays out of my way.
The takeaway
Every line on a software bill is a decision someone made — either to spend the money, or never to question that they were spending it.
Most “standard SaaS stacks” are accidents. They’re what happened when nobody, over five years, asked of any individual line, “do I actually need this?” The bill is large because nobody refused.
Worse: many of those line items aren’t accidents — they’re vanity. Tools picked because they look serious on an architecture diagram. Dashboards subscribed to because the competitor mentions them in conference talks. “Enterprise” tiers paid for because they signal seriousness to investors.
Spending money you don’t need to spend, for vanity reasons, is obscene — especially when it’s the money you’d otherwise have used to keep the business alive.
Mine is small because I refused.