There's a lot of vague hand-waving about AI product costs online, so here are my actual numbers as a solo dev, plus how I think about cost-per-request and pricing. No fluff.

The cost structure

My product does one thing: it takes a resume and returns an AI-generated analysis. The costs break into three buckets:

1. LLM API (the variable cost)

This is the one that scales with usage and the one to watch. Every analysis is one API call to a language model. The cost per call depends on how many tokens go in (the resume + my prompt) and come out (the structured analysis).

A resume is short — usually 400–800 words. My system prompt adds some overhead. The output is a structured analysis, also bounded. So each "roast" is a relatively small, predictable number of tokens. The key realization: because I cap input size and use a single call, my cost-per-roast is small and predictable — fractions of a cent to a few cents depending on the model tier.

2. Hosting (mostly fixed)

The app runs on a platform-as-a-service host. For low-to-moderate traffic, this sits in the low single-digit dollars per month, scaling up only if traffic gets serious. As a solo dev pre-revenue, this is noise compared to the LLM cost.

3. Payments (percentage, only on sales)

The payment processor takes a percentage per transaction. This only costs me anything when I actually make a sale — so it's never a risk, it just trims the margin on each paid order.

The number that actually matters: cost-per-request

Forget monthly totals for a second. The metric that determines whether an AI product is viable is cost per request versus revenue per request.

If each free analysis costs me a few cents in API spend, then:

A few hundred free users cost me a few dollars — totally survivable

The moment a fraction of them convert to a paid tier, the paid revenue dwarfs the API cost of everyone who used it free

The free tier is essentially a marketing cost — I'm paying cents to let someone experience the product, betting that enough of them upgrade. As long as cost-per-free-use stays tiny and the paid price is many multiples of it, the unit economics work.

How I keep the variable cost down

A few deliberate choices that keep the API bill sane:

Cap the input. I truncate input to a reasonable character limit. Resumes are short, but people paste entire portfolios. Capping prevents a single user from sending a runaway, expensive prompt.

One call, not a chain. It's tempting to make separate calls for scoring, issues, and rewrites. I do it all in one structured call. Fewer calls = lower cost and latency.

Right-size the model. You don't always need the biggest, most expensive model. Matching model tier to the task keeps cost down without hurting quality where it matters.

No wasted retries. I retry a failed call at most once. Retrying endlessly to force a perfect response just burns money.

The launch-day spike (and why I topped up early)

Here's a real lesson: when you launch and distribute hard, traffic can spike fast and unpredictably. If a post takes off, you could go from a handful of users to hundreds in hours. That's great — but every one of those users triggers an API call.

I made sure I had enough API credit before pushing for traffic, specifically so a sudden spike wouldn't hit a hard limit and break the product for the exact people I'd worked to attract. Running out of credit mid-launch is a self-inflicted wound.

How this shapes pricing

Knowing my cost-per-roast directly informed pricing. The paid tiers are priced as a one-time unlock, many multiples above the marginal cost of generating the content. Because the variable cost per user is small, I don't need a subscription to be sustainable — a one-time price comfortably covers the compute plus margin.

This is the quiet advantage of a lean LLM-wrapper: low fixed costs, tiny variable costs, and you only need a small conversion rate to be profitable. The risk isn't cost — it's getting enough of the right people to show up.

The honest takeaway

The fear that "AI products are too expensive to run" is mostly overblown for small, focused tools — if you're disciplined: cap input, minimize calls, right-size the model, and know your cost-per-request cold. The expensive mistakes come from unbounded prompts, chained calls, and ignoring the dashboard.

For a solo dev, the real constraint isn't the bill. It's distribution and conversion. The compute is the cheap part.

If you want to see a lean AI product in action, mine's live at yourcvsucks.com. Happy to go deeper on cost modeling or architecture in the comments.

So the task became: get the model to return clean, parseable JSON — every single time — even when the input is messy and unpredictable. Here's everything that actually worked, in order of impact.

Step 1: Ask for JSON explicitly, and ban everything else

The single biggest improvement came from one sentence in the system prompt:

Return ONLY valid JSON. No preamble, no explanation, no markdown code fences.

Without that explicit ban, LLMs love to be "helpful." They wrap the JSON in triple backticks. They prepend "Sure! Here's the analysis:". They add a friendly closing line. Every one of those breaks JSON.parse().

Spelling out the negative constraints ("no preamble, no fences") mattered more than I expected. Telling the model what NOT to do was more effective than just asking for JSON.

Step 2: Specify the exact schema inline

Don't just say "return JSON." Show the model the exact shape you want, with types:

Return JSON in this exact structure:

{

"score": <integer 0-100>,

"categories": {

"clarity": <integer 0-100>,

"impact": <integer 0-100>

},

"summary": "",

"issues": ["", ""]

}

The inline type hints (<integer 0-100>) cut down on a whole class of bugs where the model returned "score": "high" or "score": "85/100" instead of a clean integer. The model mirrors the structure you give it, so give it a precise one.

Step 3: Never trust the output — parse defensively

Here's the uncomfortable truth: even with a perfect prompt, the model will occasionally misbehave. Maybe one response in fifty sneaks in a code fence or a trailing comma. If your code calls JSON.parse() directly on the raw response, that one bad response crashes the request and the user sees a spinner forever.

So the backend strips known garbage first, then parses inside a try/catch:

function safeParseJSON(raw) {

// Strip markdown fences the model sometimes adds anyway

const cleaned = raw

.replace(/```json/gi, "")

.replace(/```/g, "")

.trim();

try {

return { ok: true, data: JSON.parse(cleaned) };

} catch (err) {

console.error("JSON parse failed:", err.message);

return { ok: false, data: null };

}

}

This function alone fixed most of my early "it just hangs" reports. Assume failure is possible, and the product degrades gracefully instead of falling over.

Step 4: Validate the shape, not just the syntax

Parsing successfully isn't the same as getting usable data. A response can be valid JSON but missing the score field, or have categories as a string instead of an object. So after parsing, validate the shape before handing it to the UI:

function isValidResult(obj) {

return (

obj &&

typeof obj.score === "number" &&

obj.categories &&

typeof obj.categories === "object" &&

Array.isArray(obj.issues)

);

}

If validation fails, you have options: retry the call once, return a friendly fallback, or surface a "something went wrong, try again" message. What you should not do is pass half-formed data into a UI that assumes it's complete — that's how you get cryptic frontend crashes.

Step 5: Retry once on failure (cheap insurance)

LLM responses are non-deterministic, so a response that failed once will often succeed on a second try. A single retry on parse/validation failure dramatically improved reliability for very little added cost:

async function getStructuredResult(input) {

for (let attempt = 0; attempt < 2; attempt++) {

const raw = await callModel(input);

const parsed = safeParseJSON(raw);

if (parsed.ok && isValidResult(parsed.data)) {

return parsed.data;

}

}

// both attempts failed — return safe fallback

return null;

}

Two attempts caught nearly everything. I didn't go beyond two, because if it fails twice, something else is usually wrong (bad input, an outage) and retrying harder just burns tokens.

The mental model that helped

I stopped thinking of the LLM as a function that returns data, and started thinking of it as an unreliable external service — like a flaky third-party API. You'd never call a flaky API without a timeout, a try/catch, validation, and a fallback. Treat the model the same way and your product stops being fragile.

Summary checklist

If you need structured output from an LLM:

Explicitly demand JSON only — ban preamble and code fences

Show the exact schema inline, with types

Strip stray fences, then parse in a try/catch — never raw JSON.parse()

Validate the shape, not just that it parsed

Retry once on failure

Always have a graceful fallback

That stack took my AI product from "randomly breaks in front of users" to genuinely reliable. The model is powerful but unpredictable; the engineering around it is what makes it production-ready.

If you want to see structured LLM output running in a real product, it's live at yourcvsucks.com — it parses a resume into a scored, structured breakdown. Happy to talk prompt/parse design in the comments.