Dan Haiem is the founder and CEO of AppMakers USA, helping business leaders design, build and scale apps that deliver real-world impact.
Founders often treat model selection like a one-time technical decision. They pick the best one available, integrate it and ship. What most don’t think about is that they’re not just choosing a feature. They’re making an architectural commitment that their product will have to live with long after the model they chose has changed, been repriced or been superseded by something that didn’t exist when they started building.
I’ve been watching this play out for five years. The model that dominates the conversation when a founder decides to build is almost never the model that dominates the conversation two years later. That gap is where a lot of expensive, unplanned rebuilds come from.
The Decision That Still Holds Up
In late 2020, a healthcare client came to my team wanting to build their app’s language layer around AlphaFold 2. It was generating enormous excitement at the time, particularly in healthcare and life sciences, and the enthusiasm made sense. It was a genuinely impressive piece of research.
I advised against it, not because it wasn’t capable, but because AlphaFold 2 was purpose-built for protein structure prediction. Anchoring a production app’s general-purpose language layer to a model designed for a specialized scientific task was an architectural risk that could compound over time. The product’s needs were going to grow in directions that model was never designed to support.
Our recommendation was GPT-3 instead, chosen specifically for reliability and the flexibility to evolve with the product rather than constrain it. That app still runs today. The foundation we recommended has since evolved significantly across the entire GPT family, and the client has been able to take advantage of those improvements without rebuilding from scratch. The decision was boring at the time. That’s usually a sign it is right.
What We Did Differently On Our Own Product
When we built Echo Journal, we made a deliberate architectural choice early on. Instead of integrating directly with a specific AI model, we built a model-agnostic abstraction layer between the product and whatever model sits underneath it. The goal was to maintain compute availability, stay within a sustainable budget and stay prepared for the unexpected.
Being prepared for the unexpected in AI model terms means your architecture doesn’t assume the model you’re using today will behave the same way, cost the same or even exist in the same form in two years. An abstraction layer means that when something changes, and it will, you’re making a configuration change, not a rebuild.
It was a basic lesson I learned from watching what happens when products don’t do it, not a sophisticated insight.
The Questions Worth Asking Before You Commit
Model selection conversations tend to focus on capability, and that is a reasonable starting point but a terrible stopping point.
Before writing a single line of integration code, stress-test the dependency. Pull up your product’s core user flows and map which ones break if the model you’re planning to use is deprecated, significantly repriced or changes behavior in the next 18 months. If the answer is “most of them,” that’s an architecture problem, and the time to address it is before the build starts, not after.
Then build the abstraction layer before you build the feature. It costs more upfront, and it feels unnecessary when everything is working. It stops feeling unnecessary the first time a model update breaks something in production or a pricing change makes your unit economics stop working. Direct integration is faster to ship. An abstraction layer is cheaper to maintain over a three-year horizon. Most founders optimize for the first and pay for it during the second.
Finally, document the reason you chose this model, not just which model you chose. A year from now, when a newer model is generating buzz and someone on your team wants to switch, the question will center on whether switching solves a real problem your users have. If you can’t find the original reasoning, that conversation will rely on feeling rather than criteria. So, write it down now.
The founders who build with the understanding that the AI model landscape is not stable from the start will be the ones who don’t have to explain to their board why a core feature needs a rebuild because the model it depended on no longer exists.
Remember, the best model for your product is the one your architecture can outlast.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?