The model is not the product

When I started putting AI features into real products, I thought the hard part would be picking the right model. It wasn't. The model is maybe ten percent of the work.

Here is the other ninety: deciding what happens when the model is confidently wrong, writing fallbacks for when the API times out, figuring out what part of the output a human should approve before it reaches a user, storing inputs and outputs so you can debug tomorrow what confused you today, and pricing the feature so it doesn't bankrupt you the first week it goes viral.

What actually ships

A production AI feature is a pipeline, not a prompt:

• input validation and sanitisation, because users paste everything
• a prompt assembled from context your code controls, not just the user's text
• output validation, because the model will sometimes return something your types don't allow
• a fallback path for failure — cached answers, degraded mode, or an honest error
• logging and evaluation so quality improves over weeks, not vibes

The uncomfortable conclusion

If you can swap the model and nothing about your system changes, you never built a system. You built a demo. The durable parts — the guardrails, the evaluation, the failure handling — are ordinary software engineering with extraordinary consequences for getting them wrong.

That's why I stopped asking "which model should I use" and started asking "what does my product owe the user when the model fails". The second question is answerable. The first one changes every month.