The real problem is not the technology
When a COO or CFO at a 100-person company decides to bring in AI, the first question they ask is usually the wrong one: "What tool should I use?"
The right question is: "What type of solution makes sense for this process, given the resources we have today?"
Without that distinction, companies end up in one of three familiar scenarios: they purchase a SaaS platform that no one adopts, they engage a vendor who delivers an MVP that never reaches production, or they attempt to build internally and the project stalls within two months because the team doesn't have the bandwidth.
This article proposes a three-question framework for making that decision with clarity.
The three options and what each one entails
Build means developing a custom solution, either with an internal team or with a technical partner. It offers greater control, higher upfront cost, and more time before something is operational.
Buy means acquiring an existing tool or platform — SaaS, an AI module within an ERP, a vertical solution — and configuring it for the use case. It means shorter implementation time, but less flexibility and dependence on the vendor's roadmap.
Hire means outsourcing the design, build, and operation of the solution to a specialized partner. It means speed, knowledge transfer, and an external governance model while the internal team develops its own capabilities.
None of the three is universally better. The choice depends on context.
The three-question framework
1. How critical is the process to the business?
If the process directly affects the financial close, relationships with key clients, or the core operation of the business, the margin for error is low. In that case, building from scratch with a team that has no prior AI experience introduces unnecessary risk. Engaging a partner with production experience reduces that risk significantly.
If the process is important but not critical — for example, consolidating internal reports, tracking vendors, or classifying documents — there is more room to experiment with existing tools or an incremental build.
2. Is the data available and usable?
AI does not work on disorganized data. Before deciding what to build, you need to know what data exists, where it lives, and what condition it is in.
If data is fragmented across spreadsheets, emails, and disconnected systems, a generic SaaS platform will not solve the problem. Preparation work will be required, and that work is part of the real cost of implementation.
If the data is reasonably structured — even in Excel — and the process is repeatable, the viability of a custom solution increases considerably.
3. Who will maintain this six months from now?
This is the question most often skipped, and the one that kills the most projects.
An AI solution is not a report that gets delivered and filed away. It requires maintenance: prompt adjustments, output quality monitoring, updates when internal processes change. If no one on the team has the time or capability to handle that, the solution degrades and gets abandoned.
If the honest answer is "no one on the team can take ownership of this," then the engagement model must include external governance as part of the service — not as an add-on.
A concrete example
A distribution company with 80 employees and operations in three countries needed to consolidate its monthly margin report by product line. The process took three to four days of work from two people on the finance team, with significant exposure to manual errors.
They evaluated three paths:
- Buy: they reviewed two BI platforms with AI modules. Both required integration with their ERP, which had a limited API. The integration cost exceeded the available budget.
- Build internally: the IT team had one person with basic Python knowledge. That was not sufficient to build and maintain a consolidation agent in production.
- Hire: they worked with an external partner who designed a consolidation agent connected to their existing data sources. Within six weeks the agent was in production. The process went from three days to four hours. The finance team was trained to operate the system, and the partner maintains technical governance on a monthly basis.
The project cost was recovered in the third month, accounting only for the time freed up from the finance team. In conservative terms, the annual savings are equivalent to between 15 and 25 working days for two senior employees.
When each option makes the most sense
| Situation | Recommended option |
|---|
| Critical process, data available, no technical team | Hire |
| Non-critical process, market tool that covers 80% of needs | Buy |
| Differentiating process, technical team available, sufficient time | Build |
| Critical process, disorganized data, no technical team | Hire with a data preparation phase included |
What doesn't work
Buying a generic platform for a process that requires business-specific logic. The typical result is a tool that gets used partially for three months and then abandoned.
Building internally without a proven method. The team learns, but the project does not reach production within the timeframe the business needs.
Engaging a vendor who delivers the project and disappears. Without ongoing governance, the solution degrades.
Conclusion
The build, buy, or hire decision is not a technical one. It is a business decision that depends on process criticality, the state of the data, and the realistic capacity for maintenance.
For most companies with 50 to 200 employees and no established technical team, the most effective combination is to hire a partner who builds alongside the internal team, transfers knowledge, and maintains technical governance while the organization develops its own capabilities.
If you want to apply this framework to a specific process at your company, you can request a free diagnostic. In under a week, you will have a concrete recommendation on which path makes the most sense for your situation.
