Pick the model. Skip the wedding. Every AI MVP starts with a model choice the founder is asked to make in week one — months before the data needed to make it well exists. Standard advice (“pick the best model and iterate”) treats that first choice as a marriage. The model-without-lock-in pattern treats it as a rental with a clean exit. Four ingredients — a thin model abstraction layer, model-version pinning, a cross-vendor eval set, and prompt shapes that transfer — turn the first decision into a default whose swap costs an afternoon, not a sprint.
This article extends the eval-first build playbook within the idea-to-product manifesto. Where the playbook argues the eval set is the spec, this article argues the eval set is also the artifact that buys you out of a vendor decision made too early.
Table of Contents
- Why your first model choice is a procurement risk
- The four ingredients of the pattern
- The three founder traps
- Worked example — a four-hour vendor swap
- What the pattern costs to install
- Frequently Asked Questions
- Closing
Why your first model choice is a procurement risk
A 2018 SaaS MVP let the founder defer the database vendor decision for months — switching Postgres to MySQL six months in cost a weekend. The application spoke to an ORM; only the driver knew the vendor.
A 2026 AI MVP looks similar in the diagram and behaves nothing like it. The application calls one vendor SDK directly, prompts are tuned to one model’s tool-calling convention, and the eval scores outputs from one vendor. Three weeks in, the founder has not chosen a model — the founder has been married to one by the path the code grew along. McKinsey’s State of AI reports adoption above 78% with a small fraction capturing material value; one recurring failure mode is exactly this — commit in week one, model layer shifts in week eight, the team cannot afford to re-platform.
The model layer is the most volatile dependency in any AI product. The frontier mix tracked by the Artificial Analysis leaderboard — Claude Opus 4.8, Claude Sonnet 4.6, GPT-5, Gemini 2.5 Pro, Claude Haiku 4.5, Llama 3.3 — did not exist when many in-flight MVPs picked their first vendor. Capability ranks flip; vendors deprecate with sixty days’ notice. Treating the first choice as a commitment is signing a contract with no exit clause on the most volatile line item. The pattern is the exit clause — not neutrality on which model is best (AI model selection 101 covers that), but optionality on whichever model the team picks today.
The four ingredients of the pattern
The pattern has four pieces. Skipping any one of them produces the four-week swap instead of the four-hour swap.
Ingredient 1 — A thin model abstraction layer
One module owns the model call. Everything else in the codebase talks to it; it talks to the vendor SDK. In a TypeScript MVP this is a model.ts file exporting a runModel function that takes task, prompt, schema, and model arguments and returns a result. Application code never imports the vendor SDK directly — only model.ts does.
Three implementation options carry the same shape: Vercel AI SDK (TS-native adapters for OpenAI, Anthropic, Google, Mistral), LiteLLM (Python/TS client plus optional proxy with OpenAI-compatible translation), and a hand-rolled adapter (one interface, one switch on the model parameter — sufficient for an MVP with two vendors and three tasks). The 100-line cost on day one is the price of admission. Teams that skip it pay it back as a four-week refactor the first time the model shifts.
Ingredient 2 — Model-version pinning
A model name like claude-sonnet is not a version. A name like claude-sonnet-4-6-20260301 is. Pinning to the dated version means a vendor update on the unpinned alias does not silently change evaluation behavior. OpenAI’s production best practices recommend this explicitly; the same discipline applies to every vendor.
The pinning rule: read the model version from an environment variable, record it in eval-run metadata so every pass states the exact model under test, and treat version changes as code reviews. A team that does not pin cannot distinguish “the model got worse” from “we got worse.” Eval results are noise.
Ingredient 3 — A cross-vendor eval set
The eval set is the contract for what the system must do. The same eval must run unchanged against any candidate model. If the eval is hard-coded to one vendor’s response envelope, it is not a contract — it is a lock-in artifact wearing a contract’s clothes.
A portable eval set has three properties: inputs are vendor-agnostic (same input string regardless of who runs it); the rubric grades the output, not the envelope (“the priority bucket assigned matches the human label within one level” is portable; “the choices[0].message.content field contains ‘P3’” is not); and the harness runs the same eval against two or more vendors and reports a delta. Once the harness exists, switching the primary model is a configuration change, not a refactor. This is the same eval set described in the eval-first PRD — the PRD specifies what correct means; the cross-vendor harness makes the answer reproducible against any model the team might run tomorrow.
Ingredient 4 — Prompt shapes that transfer
Prompts are not interchangeable across models. A prompt tuned to one vendor’s tool-calling convention can score 90% on that vendor and 40% on a model with a different convention. Teams that do not author for portability discover the gap on swap day.
Three rules keep prompts portable: use structured outputs over free-form parsing (every frontier vendor supports a JSON-schema-bound response mode — the schema is the largest single source of cross-vendor transfer); keep system prompts short and instruction-led (a 300-word system prompt overfits to one model’s instruction-following style; a 60-word prompt naming the task, output shape, and failure mode transfers); and move examples into in-context messages, not into the system prompt (few-shot examples in user/assistant turn pairs are portable; embedded in a system prompt they are not).
The transferable prompt is shorter, more boring, harder to write — and the only one that survives a vendor swap intact.
The three founder traps
The pattern is simple on paper. The reason most MVPs do not have it is that three traps catch the founder before week three. Each trap is a default — what happens if no one actively prevents it.
Trap 1 — Pinning to one vendor in the first sprint
The team picks a vendor on Monday because the contractor is “best with Anthropic” or “we already have an OpenAI account.” By Friday, the application imports @anthropic-ai/sdk in seven files. The decision was never debated; the pin happened by import-statement accretion. The countermeasure is the module boundary in Ingredient 1 — the contractor’s preference sets the default, but the import boundary keeps it reversible.
Trap 2 — Hard-coding prompts to one model’s quirks
A prompt engineer iterates against the model on the desk. By week two, the prompt carries three phrases that work for that model and one that compensates for a specific failure mode of it. The countermeasure is Ingredient 4 plus a forcing function: run the prompt against a second vendor weekly. The day cross-vendor pass rate drops below threshold is the day the prompt has overfit. Catch it on the weekly run, not on the swap.
Trap 3 — Building evals that only score one vendor
The eval team writes a harness that calls one vendor’s API, parses one vendor’s envelope, and reports a number. Functional — and useless the day the team wants to compare a candidate model. The countermeasure is Ingredient 3 — the cross-vendor harness from day one, using the abstraction module. Adding a second vendor is one config line, not a refactor.
These traps are correlated. A team that pins in week one usually hard-codes prompts by week two and ships a single-vendor eval harness by week three. The pattern breaks the correlation by treating all three as a single architectural decision on day one.
Worked example — a four-hour vendor swap
Two teams, same MVP, same week-eight challenge. The MVP is an inbound-email triage agent. The challenge: the primary vendor announces a 90-day deprecation of the pinned model. A successor is offered with different pricing and a slightly different tool-calling convention. The founder needs to know which alternative to pick and at what cost.
Team A — no pattern
Day one: team picks Claude Opus 4.8. The application imports @anthropic-ai/sdk in the email service, the LLM-as-judge service, and the test runner. The system prompt is 320 words, tuned across two weeks to Anthropic’s behavior. The eval harness asserts on Anthropic’s response envelope.
Day 56: deprecation notice. To evaluate GPT-5 — 4 days to replace the SDK import in three services, 6 days to re-shape the prompt for GPT-5’s instruction-following style, 4 days to rewrite the eval harness to be vendor-agnostic, 2 days to run and analyze. Total: 16 engineering days. The founder is in milestone three. The team either delays the milestone or ships at risk on the deprecated model.
Team B — pattern from day one
Day one: team builds a 90-line model.ts module exposing runModel(task, input, model) with Vercel AI SDK underneath and adapters for Anthropic and OpenAI. Prompts are 70 words, instruction-led, with examples in user/assistant turns. The eval harness reads the model from environment, runs the same eval against either vendor, reports a delta.
Day 56: same notice. To evaluate GPT-5 — 5 minutes for a MODEL=gpt-5 toggle, 30 minutes to run the 24-case eval, 90 minutes to read the delta and identify the 3 regressing cases, 90 minutes to adjust two structured-output schema descriptions, 30 minutes to re-run and confirm parity. Total: 4 engineering hours. The team decides whether to stay (re-pinning to a newer Anthropic model) or migrate based on a delta the founder can read. The milestone holds.
The 16-day vs 4-hour delta is the ROI. Team B did 100 lines on day one instead of 15,000 on day 56.
What the pattern costs to install
For a 2026 MVP with a 2-engineer team, the install cost is four small things on day one:
- Abstraction module — 4 hours for a Vercel AI SDK or LiteLLM setup with two vendors wired.
- Pinning + env-config plumbing — 1 hour, including writing the version into eval metadata.
- Cross-vendor eval harness — 1 day on top of the eval set the team is already authoring (the second vendor is one config line if the abstraction layer exists).
- Prompt-portability discipline — no incremental hours, but a slightly slower first sprint writing shorter, schema-bound prompts. About 20% slower in week one, ~zero from week two.
Total: 1.5–2 engineer-days at project start, plus a weekly 30-minute cross-vendor eval run. Against an MVP build budget around $80K (typical mid-cluster fixed-price scope), install cost is well under 1% of the build. The insurance saves a 16-day refactor every time the model layer shifts — at current vendor cadence, roughly once a quarter.
For the procurement-side framing of this trade-off, see stop paying AI agencies for documentation, pay them for evals. For the broader scoping decision on what tasks belong in the MVP, see the AI feature scope test.
Frequently Asked Questions
Is an abstraction layer overkill for a one-task MVP? No. The layer is roughly 100 lines including two-vendor wiring. A one-task MVP without it commits to the first vendor by import accretion within two weeks. The cost is too small to defer.
Will an abstraction layer slow down my MVP? Marginally, in week one. The team writes the module once. From week two onward there is zero per-feature overhead.
Which abstraction tool should I pick — Vercel AI SDK, LiteLLM, or hand-rolled? For a TS-native MVP, Vercel AI SDK. For Python-native, LiteLLM. For a one-vendor pilot you intend to throw away in 8 weeks, hand-rolled is fine. The criterion is the same: application code never imports the vendor SDK directly.
Do I need to test against every vendor every week? No. The harness needs at least two vendors configured. Once a week, run the eval against one alternative and read the delta. Twice a quarter, refresh the alternative set to track the current frontier.
How do I pick the first vendor if every model is a default? Run a 1-day feasibility probe — see the AI feasibility check. Run the same prompt against three frontier models on a 10-case mini-eval. The vendor with the best price-adjusted pass rate is the default; the pattern guarantees the choice is reversible.
Does cloud-hosted (Bedrock, Azure AI Foundry, Vertex) change the answer? No. Cloud-hosted gateways add convenience (one bill, one IAM) but do not solve model-vendor lock-in. The same abstraction module wraps Bedrock or Vertex calls; the same cross-vendor eval still runs.
How do structured outputs help with portability? They bind the model to a JSON schema the application defines. The schema is the same regardless of vendor. A prompt asking for a JSON object with a numeric priority (1 to 5) and a rationale string produces a comparable object across all frontier vendors. Schema discipline does most of the portability work prompt engineering cannot.
What is the smallest acceptable cross-vendor eval set? Ten cases is the floor — the same as in the eval-first PRD. Below ten, variance is too high to distinguish a real regression from a flake. Twenty-four cases is a good MVP target.
Does the pattern apply to fine-tuned or self-hosted models? Yes. Self-hosted models are themselves a form of lock-in (operational, not commercial). The abstraction module makes a swap between a Llama 3.3 self-host and a frontier API trivial. The trap is shaping the eval to the fine-tune’s quirks instead of to the task.
When does the pattern stop being worth it? Once a product is past 18 months of production stability with a deeply integrated vendor and a fine-tune on proprietary data, swap cost rises and optionality value drops. For everything before that — including every MVP — the pattern is positive-NPV insurance.
Closing
Pick the model. Skip the wedding. The first model decision is asked of the founder before the data needed to make it well exists. The pattern is the founder’s commercial answer: not “be neutral on which model is best,” but “make the choice reversible at the cost of a few hundred lines on day one.”
The four-hour swap is the test. If a team running the pattern cannot route 100% of inference to a second vendor, run the eval, and report a delta inside an afternoon, the pattern is not installed. If they can, the founder has bought roughly a quarter of optionality on the most volatile dependency — for under 1% of MVP budget.
Get the AI MVP scoping worksheet — a one-page template covering the abstraction module, the cross-vendor eval set, and the prompt-portability rule a founder can take into a vendor conversation tomorrow.
Dirk Jan van Veen, PhD
