Part III of IV

The Model Layer

Putting a model in your product is not hiring an assistant, it is wiring one part into a spot you choose. In this part you scope your build, then climb from first call to prompt, structure, facts, and tools.

The outcome

You can scope a build to one real user and task, wire a model into it, and control what it costs and sends by climbing from prompt to context to tools.

Who this is for

Product people and builders putting their first model into a real product, who want to direct the wiring, not just approve it.

What you’ll walk out with

You arrive withYou leave with

A list of vague ideasScope one build worth shipping
Model everywhere, cost unknownGive the model one clear job
A black-box API callRead a model call end to end
Vague one-line promptsWrite prompts like specifications
Replies that break your codeGet output your code can parse
Answers from stale dataGround answers in current facts

Start with chapter one

A real incident

Two-thirds of one app category shipped their model the same broken way. The seven chapters next door wire yours the way you choose instead.

01 / 09

A real incident

Researchers watched the network traffic of 444 AI iPhone apps, and nearly two-thirds were handing out the keys to their own model to anyone looking.

The apps worked and the models answered, yet every stolen key billed the developer who shipped it. The model was never the broken part; the failure was in where the key was placed and how the model was wired in.

The Hacker News, 2026, Wake Forest University 'Mind your key' study

02 / 09

What happened

The credential sat in the app's own traffic, in plain view.

FROM: THE STUDY

Whoever grabs it can send model requests on the developer's account, and the developer pays the bill.

No wall stood between the key and the world.

Each app called a working model. The credential that authorized the call was shipped inside the app, where a tool watching the traffic read it straight off the wire.

03 / 09

What actually failed

The model returned fine answers. Three wiring choices around it failed.

The key rode inside the app, so anyone reading its traffic could reuse it.

No spend cap sat behind the key, so a stolen one billed with no ceiling.

The call ran straight from the client, with no server standing between the user and the model.

A better model would not have prevented any of it, because the gap was never in the model.

04 / 09

The pattern

This was not one careless team. It was the default way these apps were built.

282 of 444

AI iPhone apps leaked their own model credentials

28%

had fixed it 90 days after being told

model providers exposed, OpenAI the most common

When two-thirds of a category ships the same way, the wiring is the norm, not the exception, and your build inherits that norm unless you choose otherwise.

Wake Forest University, 'Mind your key', 2026; The Hacker News

05 / 09

The one idea

Putting a model in your product is not hiring an assistant, it is wiring one part into a spot you choose.

You decide where the call runs, what it can spend, and what it may send. Those are choices you make when you place the part, not properties of the model you picked.

06 / 09

The customization ladder

You climb from a first call to the rung that does the job, and you stop there.

Scope and place

Cut your idea list to one build, then decide the exact spot the model wires into.

Call and prompt

Make one real request, then rewrite a vague prompt into a spec: role, boundaries, format.

Structure the reply

Force answers into a fixed schema and validate the values before your code acts.

Facts and tools

Feed the model the current facts it needs, and wire a tool it can call to fetch or act.

07 / 09

The objection worth answering

"I will just use the best model and let it handle the rest."

The best model ran fine in all 282 leaking apps. A stronger model does not change what an app puts on the wire, and it bills a drained key no less, because the failure lived in the wiring, not the weights.

Reaching for a bigger model is often the most expensive rung on the ladder and rarely the one you need. The cheapest rung that does the job is usually a clearer prompt, a fixed schema, or a key that never leaves your server.

08 / 09

What actually fixes it

Each gap in the story maps to a rung and a design rule you can apply.

Key in the clientModel as component

→ Wire the model into a spot you choose, and keep the credential on a server the user never sees.

No spend ceilingFirst model call

→ Read the request and reply in full, so you know what tokens each call costs before you ship it.

Reply the code cannot useStructured output

→ Force the answer into a fixed schema and validate every value before your code acts on it.

Answers from stale factsGiving context

→ Feed the model the current facts it needs, by stuffing a short block or retrieving the few that match.

Every gap above is a rung you can climb, and the fix is a decision, not a better model.

09 / 09

From story to part

Every gap in that story is a rung in this part.

Seven chapters take you from scoping one real build to wiring a model into it, then climbing from prompt to structure to facts to tools, reaching for the cheapest rung that does the job and stopping there.

Start with chapter one →