AI products should solve problems, not demonstrate AI

An AI product should solve a problem someone already has, not prove that a model sits behind the screen. If you remove the model and the outcome does not change, it is a demo, not a capability. The test is the result. The label is not.

I write this as Jorge Cortés, a product engineer in Santiago. The note was already on this site. I defend it with a product I built and with the work I take under AI systems.

Why is demonstrating AI not a product?

A product exists so someone can finish a job. Book. Show up. Read a year of chat as numbers. That job was there before the model. If the model does not move it, it is decoration.

The brief often arrives as “add AI”. That is not a problem. It is a costume. Understand before building means naming the job, not the vendor.

Demonstrating AI has a shape I recognize: a chat box on the landing that owns no decision; a “powered by AI” badge on a histogram; a POST of the user’s file to a hosted model because the homepage promised intelligence; a notebook that never became a URL someone can open twice.

Those things can look like work. They are not the product. The product is the job that still exists on Tuesday, when the demo is closed.

I am not arguing against models. I am arguing against putting the model where the problem should be. In Build, the AI layer is a capability when it changes the outcome — never a demo.

Reduce until it becomes obvious and the question changes. It is not “which model”. It is “what changes for the user if this computation exists”. If the answer is “the landing looks more serious”, there is no product.

When does a model change the outcome?

A model changes the outcome when three things are true at once.

First: there is a named decision. Accept or reject. Rank. Generate a text the user could not write from a table. Classify a case that rules mis-label. If I cannot name the decision in one sentence, I do not have a place for a model.

Second: statistics and rules fail that decision at a quality the product can stand behind. Counts, thresholds, weighted sums, regex, and a parser are cheaper and clearer. They are also enough more often than a brief admits. I will not promote a score to a neural net because the landing likes the word intelligence.

Third: cost, latency, and privacy still allow it. A correct model that leaks the file, takes twelve seconds, or costs more than the credit the user paid is not a capability. It is a constraint I ignored.

If any of the three fails, I do not ship a model. I ship the computation that actually moves the job.

“Changes the outcome” is not “sounds smarter in a roast”. It is: the user would decide something different, or finish the job, only if that computation exists.

A heatmap does not need a model. A model would change the outcome if the product had to generate a paragraph that is not a template, and that paragraph is the job. I have not evidenced that WspWrapped does that. I will not claim it.

Which WspWrapped metrics need a model?

I built WspWrapped so a WhatsApp export becomes 30+ conversation metrics without storing message text. The live product is wspwrapped.online. The parser runs in memory. Only aggregates persist. Privacy is the architecture.

I did not start from “add AI to chats”. I started from a file the user already owns. The questions are the job: who writes more, who starts, who replies at 3am, who goes silent, who deletes. The data is in the export. The work is to turn it into numbers without turning it into a database of other people’s messages.

If I persist text, I become a store of intimate data. If I POST the transcript to a hosted LLM, I transmit that store. The FAQ says we do not store the content of messages. A demo that ships the chat to a vendor fights that sentence.

I split the landing’s surfaces into two piles. This split is a criterion. It is not a claim about every line of production code. Where I have not evidenced a model, I will not invent one.

Statistics or rules. Counts, heatmaps, response times, emojis, night-owl hours, double-texting, deleted messages when the export still has a tombstone, initiative after a gap. Ghosting, as the landing ships it, is a threshold on silence, not a classifier I have documented. Interest Level is described as response times, initiative, and engagement: features from timestamps and senders. None of those need a model. An AI badge on a heatmap is demonstrating AI on top of a count.

Method I will not upgrade without evidence. The landing also sells Couple Dynamics, Compatibility on five dimensions, Romance Score, AI Predictions, The Roast, Psychological Insights. Compatibility is a score: weighted sum or model. AI Predictions is copy: the future of the chat based on patterns detected by artificial intelligence. The Roast can be a template over features or a completion from an LLM. I do not name a vendor. I have not published the runtime of those surfaces here. If they exist, they run on aggregates and features in the same request, or they are templates. Not on the transcript. Features in, text out.

That is the same rule I sell as AI systems: the model is a capability inside a product with a data contract. It is not the homepage.

The parser is the hard engineering. If I assume one export format, I invent participants. The fix for a bad parse is a better parse, not a model. The model, if it exists, sits downstream of a file I already turned into numbers.

Why do cost, latency, and privacy decide before the model?

A consumer report has a price. One credit is one full report. Three credits are $2.99. Ten credits are $4.99. Credits never expire. There is no subscription. Usage is episodic: one chat, once, to post a story.

If each report calls a hosted model on the full transcript, three things break.

Cost. The user paid for a pack, not for a token budget. A long group chat is tens of thousands of lines. A completion over that text can cost more than the credit. I did not publish inference cost. I do not need a third-party statistic to know that tokens are not free and that $2.99 for three reports is a constraint.

Latency. The landing says metrics in seconds. That is a product claim, not a benchmark I published. A parse plus histograms can meet it. A model roundtrip may not. A share card that arrives after the user has closed the tab is not a card. Latency is whether the job finishes while the intent is still there.

Privacy. Personal chat is not analytics telemetry. If I persist message text, I operate a store of intimate data. If I send the transcript to a vendor, I move that store. The FAQ still has to be true: parse in memory, persist aggregates, drop raw text. A new metric is not recomputed on old reports. The user re-uploads.

These three are not ethics slides. They are product constraints. If the model violates one of them, I do not “add AI later”. I change the feature until the constraint holds, or I cut the feature.

Serverless time and memory are the same envelope. I ship on Vercel. A 50MB chat is a real export. A model that needs the whole file in a prompt makes that envelope worse.

The data contract is written before the model is chosen. WspWrapped may remember numbers. It may not remember sentences. Auth is a wallet for credits and a share URL, not a replica of the export. What a given product may send to a model is a Think decision, written down, before Build.

How do you design a feature as a capability, not a demo?

“AI as a capability, not a gimmick” is already a line on this site. In a feature, it has a sequence.

Name the job, not the stack. The WspWrapped job is to turn an export into a report and a 9:16 card. It is not “chat with your chat”. A chat box would demonstrate AI. The card is the product.

Put the model, if any, behind a named decision. Example of a decision: generate a roast paragraph from features, inside the same request, without the transcript. Example of a non-decision: stamp “AI” on a heatmap. If I cannot write the decision, I do not rent a model.

Design the data contract first. If the feature cannot live with that contract, the feature does not ship. Do not loosen the contract so the demo fits.

Show the user the work, not the machinery. If a surface is a template, it should not wear an AI badge. If it is a model, it should say it runs on features, not on the transcript. A demo needs the badge. A capability needs the result. WspWrapped’s H1 is about the chat and the truth in the file, not the model.

An AI feature that cannot be named without the word AI is almost never a feature. First the problem. Then the computation. Then, if it is needed, the model.

How I apply this

When a brief says “add AI”, I run this list. I use it on my own products. I use it when I take work under AI systems.

1. 01/

   Write the user job in one sentence. If the sentence is “show that we use AI”, stop. There is no product yet.

2. 02/

   Write the output: a number, a ranking, a document, a card. Name who uses it and when.

3. 03/

   Produce that output with parse, counts, thresholds, or a formula. Ship that if it already finishes the job.

4. 04/

   Ask whether a model would change that output in a way the user can see. If not, the model is a demo. Do not add it.

5. 05/

   If yes, name the decision the model is allowed to make. Write what it must never keep. That is the data contract.

6. 06/

   Check cost against the price the user pays, latency against the moment of intent, privacy against the file they handed over. If one fails, cut the model or change the feature. Do not hide the failure in a vendor.

7. 07/

   Put the capability inside the product surface — the report, the booking, the page — not in a separate demo URL.

8. 08/

   Label statistics as statistics. Label model output as model output. Do not sell a histogram as intelligence.

The list is short on purpose. If a step needs a slide, the problem is still unnamed.

A product with a model is still a product. The model is a layer. It earns its place when it changes the result of a job someone already had, under cost, latency, and privacy the product can keep. WspWrapped is the case I can show: the file in, numbers out, no message stored. If a surface wears an AI label, it still has to obey that contract. The rest is a demo. I do not ship demos. I ship the job.