Three options, not two
"Buy or build" is the usual framing, and for AI products it leaves out the option most teams end up choosing.
- Buy means a finished product you configure: a hosted sign-in service, a payment processor, a support tool with an assistant already built in. You get the outcome and accept their way of doing it.
- Build means you write it and run it: your own model hosting, your own retrieval pipeline, your own authentication. You get full control and the full maintenance burden.
- Glue means you call other people's APIs and models and write the code that connects them: the prompts, the tools, the data flow, the checks. You own the behaviour without owning the infrastructure.
Most AI products are mostly glue. That isn't a criticism. The value is in what you connect, the data you bring to it, and how reliably the whole thing works.
The decision is made per capability, not per company. A sensible stack is usually a mixture of all three.
Five criteria
1. Is it your differentiator? If customers choose you because of this capability, you need to control it, which means build or glue. If they'd never notice who made it, as with sign-in or invoicing, buy. Be honest here: founders tend to believe more of the stack is special than customers do.
2. How sensitive is the data? Know what data each option sends where, how long it's kept, and whether it may be used for training. For much business data, a hosted service with suitable contractual terms is fine. For regulated or highly confidential data, the answer may push you towards running things on infrastructure you control. Read the provider's terms, and take proper advice if you're in a regulated sector.
3. What does it cost at scale? Bought products often charge per seat or per transaction. Hosted model APIs charge by usage. Things you run yourself cost hardware and people whether or not anyone is using them. Work out the cost per core action at your current volume and at a much larger one. The cheapest option at the start is often not the cheapest later, and that's acceptable if you know roughly where the lines cross.
4. What's the exit cost? Lock-in isn't a reason to avoid a vendor. It's a cost to estimate. Ask what you'd have to do to leave: export data, rewrite an integration, retrain staff, re-test prompts against a different model. If the answer is "a week of work", lock-in is a small concern. If it's "rebuild the product", think harder.
5. How fast do you need it? Buying is fastest, gluing is next, building is slowest. Before you have users, speed usually outweighs everything except data sensitivity, because the largest risk is building something nobody wants. That is the same argument I make for cutting MVP scope.
Applying it to the AI stack
| Capability | Sensible starting point | Revisit when |
|---|---|---|
| Language model | Glue: a hosted model API | Data must stay on your infrastructure, or volume is high and steady enough to justify running your own |
| Vector search | Glue: the vector feature of a database you already run | Search quality or speed becomes a limit you can measure |
| Orchestration | Build thin: plain code calling the model API | Workflows grow complex enough that a framework removes more code than it hides |
| Authentication | Buy | Rarely |
| Payments | Buy | Rarely |
| Prompts, evaluation, domain logic | Build: this is yours | Never hand this over |
Hosted model APIs versus open models you run
A hosted API gives you a capable model with no infrastructure, billed by usage. You can start the same day and switch model versions by changing a setting. The trade-offs are that your data passes through a third party, your costs grow with usage, and the provider can change prices or retire a model version on their schedule, not yours.
Running an open model yourself reverses those trade-offs. Data stays where you put it and nobody can retire the model from under you. In exchange you pay for hardware whether it's busy or idle, and you take on the work of serving, monitoring and updating it. There's also a middle path: open models served by a hosting provider, which removes the operations work but not the third party.
For a first version, I'd start with a hosted API in nearly every case, and keep the model call behind a single module so the choice stays open.
Vector search
First check whether you need it. If the material the model must draw on is small, you may be able to pass it in directly. If you do need retrieval, the simplest route is usually the vector capability of a database you already run; PostgreSQL has the pgvector extension, for example. A dedicated vector database is worth considering once you have a measured problem with quality or speed, not before.
Orchestration frameworks
For wider product decisions, see the mobile architecture series.
Authentication and payments
Buy both. Neither will win you a customer, and both can lose you all of them. Handling card details yourself brings security compliance obligations that a payment processor's hosted checkout largely takes off your hands. Sign-in done badly is a breach. This is the clearest case in the whole stack.
When to revisit the decision
A choice that was right before launch can be wrong a year later. These are the signals worth watching:
- The bill becomes a significant line. When usage-based costs start to shape your pricing, run the numbers on the alternatives.
- A customer's data requirements change the answer. A large customer who needs data kept in a particular place can justify infrastructure you'd never have built speculatively.
- You hit a quality ceiling. The bought product can't do what your users now need, and configuration won't close the gap.
- The vendor changes the terms. A price change, a retired model or a new restriction is a prompt to re-check your exit cost.
- A commodity became your differentiator, or the reverse. If something you bought is now the reason customers choose you, bring it closer. If something you built is now available off the shelf, consider letting it go.
Put a date in the calendar to review the stack against these signals. Decisions that are never reviewed turn into assumptions.
What to read next
The choices above are far easier to change if the AI parts of the product were built with a few habits from the start. Those habits are in why most AI MVPs need a rebuild. The rest of the series is under Shipping AI products fast.