Build vs Buy AI: What Engineering Leaders Get Wrong
The four options for adding AI to your product, and why most teams pick the wrong one.
If you're a CTO, VP of Engineering, or technical founder at a SaaS company, you've probably had some version of this conversation in the last six months: the board wants AI features. The product team wants AI features. Your customers are asking for AI features. And your engineering team is already fully committed to a packed roadmap.
The question isn't whether to add AI. That's been decided for you by the market. The real question is how to do it without breaking everything else. Most teams jump straight to implementation without thinking clearly about the tradeoffs. Here are the four options, honestly evaluated.
Time to first AI feature by approach
Build it in-house
Hire ML talent, train or fine-tune models, build the infrastructure from scratch. This is the option that feels most natural to engineering teams because it's what they do: build things.
But you're not just building the AI feature. You're building the infrastructure to support it: model serving, prompt management, context windows, evaluation pipelines, observability, cost tracking.
The real cost isn't the ML engineers you need to hire (though senior ML roles take 3-6 months to fill). It's the engineers you pull off your core product. Every sprint your best people spend on AI infrastructure is a sprint they're not spending on the product your customers are paying for.
Acquire an AI startup
Buy a company that has already built what you need. Acqui-hire the talent along with the tech. The deck always says "seamless integration in 90 days." Reality is messier. The timeline balloons when you factor in deal process, due diligence, and the cultural integration that rarely goes smoothly.
No-code agent builders
Tools that let you configure AI agents through visual interfaces. Drag, drop, connect, deploy. Lower technical barrier and good for prototyping. You can have something demo-ready in a day.
The problem: production-ready configurations can still take months. Limited customization means you hit walls quickly. Complex workflows don't fit in a visual builder. Enterprise security requirements (SSO, audit logs, field-level access control) are often missing. And when something breaks at 2am, your team can't debug a visual pipeline the way they can debug code.
Embedded AI
A purpose-built AI layer that drops into your existing product. Your users get AI-powered features. Your engineering team doesn't become an AI company.
"Embedded AI" means AI capabilities integrated directly into an existing software product, seamlessly, from the end user's perspective, without the product team building the underlying models or infrastructure. It's not a chatbot bolted onto your website. It's AI that lives inside your product and feels like it was always there.
The honest tradeoff: Some vendor dependency. We address this directly: 90% of the Amodal runtime is open source. Your configuration lives in a git repo you own. Skills are markdown files. If you leave, you take your work with you.
of enterprise apps will embed AI by 2027
Gartner, 2025
At a glance
"If we started today, what would we actually be able to ship in 90 days?"
If the answer is "an MVP with significant caveats," you're probably looking at option 1 and underestimating the timeline. If the answer is "we don't have the people," options 1 and 2 are off the table. If the answer is "we need something production-grade, fast, that our team can maintain," you're in embedded AI territory.
Amodal is an open-source agent runtime. Configure AI agents with a git repo of markdown files.