How to make money with Claude, instead of just spending money on it

Most advice on how to make money with Claude stops at the demo. Someone one-shots a game, the timeline claps, and nobody mentions the thing needs months of real development before a human being would pay for it.

Your API invoice, meanwhile, is due now.

That gap is the whole problem once a top-tier model sits behind pay-as-you-go credits instead of a flat subscription. Every serious run costs real money, upfront, before you know whether the work lands. So you need a test — a boring, unromantic one — for deciding which jobs get the expensive model and which get the cheap one. Below is the test I use, the client deliverable it justified for my agency, and the part the model still could not do for me.

Why cool demos don't pay the bills

There is an entire genre of AI content built on things that look shippable and aren't. A game that runs. A tool that renders. An app that demos beautifully for ninety seconds. Everyone watching knows, on some level, that each of those needs a tremendous amount of further development before it's a business or even a deliverable. We clap anyway.

The trap isn't that the demos are fake. It's the timing. Your API cost is present tense and your revenue is hypothetical. You buy the credits upfront, you burn them producing something, and then you find out whether anyone wants it. You might get zero users. Nobody pays premium API prices for a future promise, least of all the lab billing you.

So the question is never "is this model impressive." It's whether the output of this specific run is something a person has already agreed to pay for, or is credibly close to it.

The three questions I ask before spending API credits

This takes about ninety seconds and it has saved me more money than any prompt trick.

1. What's your baseline for deliverable output?

   Are you using AI for internal brainstorming, or do you have paying clients expecting flawless, production-ready results? Those are different economies. Brainstorming tolerates a mediocre draft; a client proposal does not. Only the second one has a price attached, and only the second one justifies a premium bill.

2. Does the marginal improvement translate into real dollars?

   Say the better model is 10% smarter. Fine — does that 10% compress your delivery time or increase your contract value? If you can't draw a line from the quality jump to a number on an invoice, the answer is no, and you stick with the cheaper model. "Smarter" that doesn't move a dollar figure is a hobby expense.

3. Is the upfront cost below the labour value it replaces?

   The last gate is the strictest. Unless the upfront API cost is meaningfully lower than the labour value the model replaces or creates, it doesn't go into your core infrastructure. Not as a trial, not "to see what happens." You want hard business justification here, not emotional attachment to a model you like using.

What the expensive model bought on a $70,000-a-month account

Here's the run that passed all three gates, and the reason I have an opinion about any of this.

One of my agency's clients pays us $70,000 a month for marketing — north of $800,000 a year, close to a million. They do around $200 million in annual revenue in Korea; we run their overseas side.

Their contract expired in June and the renewal was not a formality. After a year and a lot of their money, the brief was blunt: convince us why we should keep investing, show us how you'll improve, and justify scaling the ad spend.

The deck the renewal turned on

The whole deal hung on one proposal deck. They wanted target revenue, a sales forecast, the marketing budget, how we operate, and how we plan to improve — four or five load-bearing sections, each with numbers we'd be held to.

I told my team to drop what they were doing, put every direction and figure they had into the model, and trust it. Deadline was July 7th. I gave one teammate two days, sat with her through the revisions, and we sent it.

Organising past data is not the same as reasoning about it

The difference showed up in exactly one place: the gap between a model that arranges what you give it and a model that thinks about it.

On the previous generation — Opus 4.8 for us — the model could simulate and organise past data competently, and I'd feed it context here and there, but I always had to touch a lot. Design revisions constantly. Forecast sections with spots that simply didn't make sense. Worse, the reasoning underneath wouldn't match the numbers: the chart said one thing and the paragraph explaining why the figures moved said another.

Catching that costs more attention than writing it yourself. If you want the design half of that fight solved properly, I wrote up the four steps that turn Claude into a design genius separately.

More room to reason

Giving the newer model more room to reason changed which parts came back usable. It analysed, produced the simulation, and suggested the moves I would have suggested. The plans matched the graphs. The reasons behind the numbers held up on read. Failure rate on the design side dropped too — fewer broken layouts to repair per pass. My revisions collapsed to a single section instead of the whole deck.

Where the human touch still had to override the model

One section. The revenue line.

The forecast the model produced dipped in the early months before climbing. Defensible on the numbers, wrong for the room. I know this client, and I know they want to see a line that sits at least above where it was two months ago — so I raised those early figures myself, and adjusted the ones downstream to match. That's not the model failing. That's client psychology, and it isn't in the training data.

The stakes are why. We run their TikTok Shop operation and we set monthly and annual sales targets in that deck. Forecasting those honestly is grueling work, because we can't sell dreams — there are weekly and monthly calls where those exact numbers come back. Miss a target and we owe a clear explanation of why the return on ad spend was bad and what changes next month.

These are not college-project numbers. If it goes in the deck, we get held to it on a weekly call.

Which is the honest version of "AI did my client work." The model did the structure, the analysis and most of the argument. The judgement about which number I'd be defending in six weeks stayed with me.

The leverage equation: API cost versus labour value

Look at your team leverage before you look at the model's benchmarks.

If you don't have employees or teammates who can design, build or operate, an advanced model is a solo multiplier — it's the hire you haven't made. If you do have a team, it multiplies their hours instead. Either way the formula is the same one from gate three: unless the upfront API cost is significantly lower than the labour value it replaces or creates, it doesn't belong in your core infrastructure.

The reason that formula bites is that failed automation isn't free. We tried automating this same deliverable in an earlier era of models. The results were completely undeliverable — broken layers, design logic scrambled, numbers that felt off. My team spent more time repairing the model's mistakes and going back and forth until the whole thread degraded than they would have spent building the deck from scratch. Negative leverage, paid for in credits.

When a model saves your team days of high-end design labour on an account that size, the expensive API bill stops being a cost centre and becomes a high-margin investment. That's the whole conversion, and it's arithmetic rather than vibes.

The same arithmetic is why I keep a hard eye on running costs elsewhere too — I wrote about the agent that was quietly burning $18 a day, and about handing my video editing to Claude Code, where the labour saved is measured in hours per upload rather than deals per year.

What to do when the next heavy model drops

Access is fragmenting. One lab pulls its strongest model behind pay-as-you-go credits; the next is lining up its own heavy hitter — GPT-5.6 was the one queued up when I recorded this. It'll keep happening, and each release will arrive with a wave of people buying credits they have no job for.

Don't panic-buy. Credits earn nothing sitting in an account. Take one real deliverable — the one with a deadline and an invoice attached — and run it through the three gates. If the model systematically buys back your time or saves a client contract, write the check without flinching. If it doesn't, hold your money and maximise your credits when the thing you actually need it for shows up.

My use case is worth the money. Building things for fun is a completely different calculation, and pretending otherwise is how people end up with an invoice and a prototype nobody asked for. Everything I ship goes through the same test — the rest of the build logs are here, and your own API usage dashboard is worth reading before you commit.

Frequently asked questions