We surveyed 100+ IT and security leaders navigating AI automation to understand how they're approaching build vs. buy. Their strategies range from in-house development to ready-made solutions, and most are already deploying something.
Have doubts about the best option for you? Here are some practical insights for guidance.
What to take into account
1. Security and compliance requirements
Organizations adopting AI need a solution that satisfies legal, compliance, and risk teams at once. Custom builds almost never have a full security package from day one. You'll need time to implement audit logging and data access controls. Retrofitting governance is even harder.
With ready-made solutions, things are more straightforward. You can check security guardrails and compliance with SOC 2, ISO 27001, or GDPR right away. Good vendors also have detailed documentation for audits.
"When you build in-house, everything a vendor normally carries becomes your problem. You'll have to manage data boundaries (what the tool can read and on whose behalf), prompt injection once it touches untrusted content, and supply chain, including dependencies and MCP connectors. Audit logging and governance always get retrofitted, and retrofitting is where teams fail."
— Artem Bovtiukh, Senior IT Security Engineer @ MacPaw
- Third-party → Vendor meets security and regulatory needs out of the box
- Custom only → Uncommon security and regulatory needs with internal expertise to meet them
2. Obvious and hidden costs
As new models become more sophisticated, token usage can exceed budgets in days. But the token bill is only the visible part. A custom build also means managing everything around it, including infrastructure, monitoring, maintenance, and continuous optimization as models evolve. It takes dedicated engineering time and racks up costs with no end in sight.
With a vendor, you typically get a more predictable price and know it upfront. You may pay more per month than for raw token use, but they handle much of that operational complexity.
"Costs and ability to access data are the two biggest barriers for AI automation at this time. We are looking for tools that can have measurable ROI, which is challenging in AI's current state."
— Zola, Chief Information & Security Officer
- Third-party → Predictable pricing matters more than owning the cost stack
- Custom only → You can absorb the overhead, and usage volume justifies it
3. Complexity vs. quick adoption
A custom tool lets you use AI where you really need it. No extra features, and the system is easier to keep explainable. A vendor product, by contrast, is built to serve many uses because its target audience is broader. Sometimes, it means more surface area and complexity.
The right choice comes down to whether a vendor's existing offering matches your business needs. If yes, established UX and pre-tested workflows will get you to adoption faster than a custom build. If not, custom gives you a cleaner, simpler system than adapting a general-purpose tool would.
- Third-party → Vendor's scope matches your use case
- Custom only → You need something narrower or simpler
4. Knowledge base readiness
To make AI reliable, your knowledge base needs to be clean, current, and structured. With custom development, the problem is often invisible until a build is already underway.
Based on our AI at Work report, 32% of organizations estimate their knowledge base to be less than 50% accurate. Teams assume their documentation is "mostly fine" and discover otherwise only once a newly launched AI system gives wrong answers.
Third-party tools that treat knowledge maintenance as a product feature can automatically flag or filter outdated pages. A messy knowledge base is less of a blocker than it would be for a custom build. You'll still need ongoing maintenance either way, but with a vendor, someone's already doing a part of it.
- Third-party → Knowledge base is not fully ready, but a vendor tool can help clean it
- Custom only → Already clean, structured, and continuously maintained data with a dedicated owner
5. Engineering capacity
AI is changing all the time, and keeping up may be difficult unless you have in-house engineering capacity both for initial development and subsequent maintenance. You'll need to monitor for failures, debug drift as models update and data changes, manage prompt versions, and respond to edge cases.
When cooperating with AI vendors, maintenance is partially done for you. You still have to manage data fed into the system, business processes, and configuration, but the vendor takes care of the core platform. Although monthly charges can be significant, you avoid having to keep a large engineering team for software support.
"Shipping is a one-time cost. The threat model isn't since every model upgrade or new integration reopens the security review."
— Artem Bovtiukh, Senior IT Security Engineer @ MacPaw
- Third-party → Team is stretched or lacks dedicated AI/ML capacity
- Custom only → Team has skills and bandwidth to build and own the system
6. Unpredictability risks
A custom model that works in a demo or staging environment behaves differently once it touches live data. An actual consequence often comes as a surprise.
With custom builds, you'll need to define what an agent is allowed to do and how to roll back unpredictable outcomes upfront. This requires experience and a strong architecture not every team has. On the other hand, software providers have already tested their AI tools across many customers and have guardrails. You get what you expect.
- Third-party → You haven't yet built the architecture to define failure modes and rollback before going live
- Custom only → The reliable architecture, failure rules, and rollback procedures are in place and tested
7. Prior failures
If your team has already tried to build something internally and failed, trust this sign. When the underlying causes are structural and unlikely to change, switching to a vendor may be a smarter move. Most teams don't suddenly acquire missing production architecture or governance just by trying again.
Only if you know exactly what went wrong, another try may be worth it. Make sure you understand the root cause and have the necessary expertise to do things differently.
"If you have never run a production AI system before, buy and learn on someone else's guardrails."
— Artem Bovtiukh, Senior IT Security Engineer @ MacPaw
- Third-party → Previous custom build stalled or broke in production because of structural flaws
- Custom only → Root cause of failure is identified, and you can fix it
8. AI governance model
Vendors provide built-in governance features from the start. Access controls, audit logs, and centralized administration are often part of the product. But that governance only covers the platform itself. Other AI tools your employees use remain unsupervised. With a custom build, you can design governance exactly as you need, taking into account all existing identity and access systems.
Whatever you choose, governance will not be established automatically. Someone still has to build, manage, and maintain it.
- Third-party → No centralized AI governance model in place yet
- Custom only → Mature governance infrastructure already exists
9. Unique data and workflows
If you have rare data and workflows, custom development is typically better. But note that some workflows feel distinctive internally, while in reality, there are already many AI solutions for them.
Run a business analysis and carefully inspect the market before planning development. Buying often gets you the same outcome faster, with less risk, and without the maintenance burden.
- Third-party → Use case matches existing offer
- Custom only → No vendor has a tool for your data or workflows
10. Integration capabilities
Custom builds have an advantage if you need to connect AI with legacy systems and no vendor connector exists. Third-party platforms are typically better when standard integrations cover your needs. Pre-built connectors for tools like Confluence, Slack, and Okta eliminate months of engineering work.
"The lack of a maintained connector for a critical legacy system is one of the top cases when a custom build is worth it."
— Artem Bovtiukh, Senior IT Security Engineer @ MacPaw
Map your required integrations explicitly, system by system. Then, check which ones already have a maintained vendor connector and which ones don't to decide whether to build or buy.
- Third-party → Required integrations are covered by pre-built vendor connectors
- Custom only → No available connectors for critical legacy systems
11. Data access
A custom build keeps data access entirely within your systems, with permission boundaries you design and audit. No data will leave your environment if you don't want it to. This is a real advantage when the data is too sensitive, too regulated, or too specific to be handed outside. However, it works only if your team knows how to build and enforce strong access controls.
With off-the-shelf solutions, your main control is the choice of vendor. Look for transparent data policies and certifications like SOC 2 that back up their claims.
"The nature of our work puts a lot of sensitive and proprietary data in play, so we heavily vet each and every tool before deploying them for mass usage. Data security is the forefront of our policy base and can often feel like a barrier."
— Kenya, IT Director
- Third-party → Not strictly regulated environment, and the potential vendor has transparent data policies
- Custom only → Data is too sensitive or regulated to leave your environment, and you can build access controls
About Leebry
Leebry is a Work AI platform designed to help organizations make better use of the knowledge and tools they already have. By connecting systems like Confluence, Slack, Jira, Okta, and HRIS, it provides secure, citation-backed answers and enables everyday workflows through a single interface.
Leebry is built by MacPaw, known for products like CleanMyMac, Setapp, and ClearVPN, as part of its move into enterprise AI.
