Post 1 of 4 in the *Building With LLMs* series.
A quick note on scale before we go further. The app this series is based on is a small LLM app — twenty-three prompts, twenty-one distinct AI calls, run by a small team. The numbers and anecdotes throughout reflect that. But everything below works as a guiding principle at any size: a solo founder with a single Claude integration, a Series-A startup with a dozen calls in production, an enterprise with hundreds across multiple products and business units. The math gets more consequential as you scale up — a 30% reduction on $100/month is interesting, the same 30% on $100,000/month pays for an engineer — and the operational risks grow with the bill (drift across teams, untracked calls, model-pricing changes that hit a hundred call sites at once). The playbook itself doesn't change. The discipline of running it does.
The question that kept coming up while I was working on this audit: should you even be building a SaaS right now?
It's a fair question. AI generates code well enough that one person can produce in a weekend what used to take a team a quarter. Tests get written. Boilerplate gets boilerplated. Regression suites get regression-suited. CI keeps the lights on. The cost of building software is collapsing, and it's not done collapsing. So yes — the existential question is real. If you're sitting on the fence about whether to build the thing, the cheap-execution part of the equation has shifted under your feet, and you should think about it before pouring the next year of your life into it.
So let me try to answer it honestly, then move to the second half of this post — how to use AI tools well if you do build.
## What got cheaper, what didn't
What got cheaper is execution. If you can describe what you want clearly, you can have it. The hard part of building is no longer "how do I implement this," it's "do I understand the problem well enough to describe it." That's a real shift. A solo founder today can ship things that needed a small team eighteen months ago.
What didn't get cheaper: distribution, judgment, taste, customer trust, knowing what to build in the first place. AI doesn't tell you which feature to ship next. It doesn't talk to your customers. It doesn't have skin in the game when something goes wrong at 2 AM. And — increasingly important — it doesn't help you stand out in a market where everyone else also has AI generating their features.
The moat used to be "we can build this and they can't." That moat is mostly gone. The new moats are slower and less satisfying: a real understanding of the user, a unique source of data you've earned, a distribution channel you've built, taste that's genuinely yours, a domain you've spent years inside. The good news for SaaS builders is that those moats are deeper and harder to copy than the old one ever was. The bad news is that you can't ship them in a weekend.
If you're trying to decide whether to build, the honest test isn't "can AI do this?" — it almost certainly can. The honest test is: do I see something here that isn't obvious, that I'm willing to work on for the years it takes to be good at it? If yes, build. The execution being cheap is a gift; it means you'll get to test the idea faster, which is what matters. If no, the execution being cheap won't save you. Building the wrong thing fast is still building the wrong thing.
## If you're building, how to actually use AI tools
Whether the AI is writing your code, drafting your prompts, generating marketing copy, or helping you debug — the same handful of habits separate the teams that get real leverage from the ones that end up with a pile of confidently-wrong output they don't understand. None of these are clever. All of them take more discipline than they should.
Treat the AI as a colleague, not an oracle. A colleague gets things wrong, and you double-check their work. An oracle is supposed to be right; when it isn't, you don't have a process for catching it. The colleague framing keeps verification as a habit instead of an afterthought.
Be specific. Vague in, vague out. "Make this faster" produces hand-waving. "This SQL query takes 3 seconds on a table with 5M rows; the explain plan shows a sequential scan on user_id — what index would help?" produces something useful. Specificity is the single biggest lever on the quality of AI output. You're not being polite, you're giving the model the context it needs to actually do the work.
Ask it to show its work. When the AI gives you code, ask why. When it gives you a recommendation, ask what alternatives it considered and why it ruled them out. The answer often reveals that it didn't actually consider alternatives — at which point you know to push harder before you trust the output.
Read what it produces. Don't paste-and-pray. This is the most common mistake I see. The AI generated 200 lines of code, it compiled, the test passed, you moved on. Three weeks later the bug shows up in production and nobody on the team — including the person who "wrote" it — can explain what it does. If you didn't have time to read it, you didn't have time to ship it.
Iterate in small chunks. "Build me the whole authentication system" gets a confident-looking answer with subtle wrongness throughout. "Give me the password-hashing function and explain the cost factor choice" gets something you can actually verify. Small steps mean small recoveries.
Use it for what it's actually good at; be skeptical for the rest. AI is excellent at boilerplate, refactoring, summarization, code explanation, finding things, and drafting. It's mediocre at architecture decisions, novel design problems, taste, and the unwritten rules of your specific codebase. Knowing the difference saves you from outsourcing the wrong work.
Don't outsource the thinking. Outsource the typing. The temptation is to let the AI do the deciding because the deciding is the hard part. Resist. The deciding is the part you're paid for. The typing is the part you're not.
Keep humans in the loop on anything destructive or hard to roll back. Database migrations, payment flows, customer-facing copy that goes out at scale, security-sensitive code. AI-assisted is fine. AI-decided is not. The cost of being wrong on these is asymmetric — slow down where the downside is large.
Save your own context. What you decided, what you ruled out, what you tried that didn't work. AI mostly doesn't remember between sessions. You're the persistent memory of your own project. Write things down — in commit messages, in design docs, in a scratch log. Future-you will thank you, and so will the AI on the next session, because you can paste the context back in.
The summary of all that: AI lets you move faster, but only if you slow down at the right moments. The teams that get the most out of these tools are the ones who resist the urge to let speed do their thinking for them.
## Coming next in the series
If you decide to build, the buy vs. build calculus has flipped on the other side too — for the customers you're trying to sell to, and for every internal tool decision your team makes. [Post 2: Buy vs. Build After AI] covers what counts as commodity now, what doesn't, and what still defends a SaaS in a world where features get cloned in a weekend.
After that, two foundational posts on the mechanics of working with LLMs in production: [Post 3: Tokens and Temperature, in Plain English] and [Post 4: Twelve Steps to a Cheaper, Better LLM App]— the tactical playbook for cutting LLM costs in half while improving quality.