Build for the next model, not this one
The model you launch on will not be the model you run in a year. A few architectural habits keep that change cheap.
Models improve every few months. Prices fall, context windows grow, and capabilities that needed a pipeline last spring arrive in a single call. A product that is welded to one model and one prompt pays for every one of those improvements with a rewrite.
The products that last treat the model as a replaceable part. Not because the model is unimportant, but because it is the part most certain to change.
Keep a seam between product and model
All model calls go through one narrow layer that owns prompts, tools, retries and output validation. The rest of the product talks to that layer in its own terms: summarise this account, draft this reply, find these leads. When a better model arrives, one layer changes and the interface does not notice.
Write the evaluations before you need them
You cannot upgrade a model with confidence if you cannot tell whether the new one is better at your task. A small set of real examples with expected outcomes, run on every change, turns a nervous migration into a routine one.
- Start with twenty to fifty real cases, including the ugly ones.
- Score what matters to users, not what is easy to measure.
- Run the set on every prompt or model change, like any other test.
Own the parts that compound
The interface, your data and the trust you build with users are the assets that get more valuable over time. The model is rented. Design the product so that what you own sits on top of what you rent, and every new model becomes an upgrade instead of a project.
