A field guide for the rest of us. Written after auditing a real LLM-powered SaaS end-to-end — 23 prompts, 21 distinct AI calls, a mix of providers and fallbacks — and writing down what we learned.
The four posts
1. Should You Build a SaaS in 2026?
The existential question first. AI generates code in minutes. Tests get written. CI keeps the lights on. So is building software still worth it — and if you do, how do you actually use AI tools well? Eight habits separate the teams that get real leverage from the ones that end up with a pile of confidently-wrong output.
2. Buy vs. Build After AI
The same question from the other side. The buyer's math has flipped — a weekend with Claude can compete with a third-tier SaaS now. But total cost of ownership didn't get cheaper. Here's what counts as commodity now, what doesn't, and what still defends a SaaS in a world where features get cloned in a weekend.
3. Tokens and Temperature, in Plain English
The two dials nearly every LLM cost and quality issue traces back to. What a token actually is, in bytes you can feel. What temperature actually does, in plain English. Short, foundational, skip if you already know — but most teams don't, and it shows in their bills.
4. Twelve Steps to a Cheaper, Better LLM App
The tactical playbook. Twelve concrete moves, in roughly the order you'd want to do them, that routinely cut LLM costs in half and improve quality at the same time. None take more than a couple of hours each. The numbers are from a real audit on a real codebase, not invented.
Who this is for
If you're building anything that calls an LLM API in production — a feature inside a larger app, a standalone AI product, an internal tool — and you care about either the bill or the output quality, all four posts will pay back the time it takes to read them.
If you're earlier — still deciding whether to build, or what to build, or whether to pay for an existing tool — start with posts 1 and 2.
If you've already shipped and you want to tighten what you have, jump to post 4 and reference 3 when the vocabulary trips you up.
Author's note
Everything in this series came from finding actual problems in actual code. None of the numbers are made up. None of the anecdotes are composites. Where the post cites a saving or a cost, it's based on a measurement, not an estimate. The names of specific models and providers are mentioned where they're relevant; the principles work across all of them.