Organizations across the Bay Area are moving past casual experimentation with artificial intelligence and into more serious questions about operating models, governance, and long-term value.
The core challenge is not simply whether to adopt AI. It is how to make disciplined choices about what to build internally, what to purchase from the market, and where outside expertise belongs. That choice affects cost, speed, control, risk, workforce readiness, and community trust.
This article is based on and independently adapted from analysis by Ankit Kapoor. It does not copy source language. It also reflects MFHC’s general strategic interest in business leadership, governance, and operational excellence, but it does not describe any documented MFHC AI implementation, investment, client result, partnership, or foundation program.
A useful AI strategy rarely rests on a single answer. Many organizations will build some capabilities, buy others, and partner where execution or change management requires added depth. The real work is deciding which path fits each workflow and doing so with enough discipline to avoid expensive pilots that never improve the business.
Why the decision matters now
AI adoption can look deceptively productive in its early phase. A team gains access to a generative AI assistant. A department tests summarization, drafting, or search. A technology lead explores agent-based workflows. Those activities can produce learning, but they do not automatically produce durable business value.
The gap usually appears when leaders try to move from demonstration to deployment. A tool may generate an answer, but the organization still has to determine who verifies the answer, how exceptions are handled, what data is permitted, what risks must be managed, and how the output enters a real workflow. Without those decisions, AI remains a side experiment instead of an operating capability.
That is why the build, buy, or partner framework matters. It forces leaders to begin with the work itself, not with vendor excitement or internal enthusiasm alone.
Start with workflow discovery before technology selection
Before an organization chooses a model, platform, or partner, it should understand the workflow it wants to improve. Process discovery often reveals that the real problem is not a lack of AI. It is fragmented data, duplicated approvals, inconsistent terminology, or unclear ownership.
Workflow discovery should answer several practical questions:
- What triggers the process?
- Which people, systems, and documents are involved?
- Where are the handoffs?
- Which steps are repetitive and rules-based?
- Which steps require judgment, escalation, or compliance review?
- Where do delays, rework, and errors occur?
- What outcome actually needs to improve?
This exercise matters because AI can accelerate a poor process just as easily as a strong one. If the underlying work is disorganized, automation may simply make confusion faster and less visible.
Build when the capability is core to differentiation
Building is usually the right path when the capability is central to how the organization creates value and when the workflow reflects proprietary knowledge, distinctive operations, or a unique customer experience.
An organization may decide to build its business logic, policy engine, workflow orchestration, internal knowledge layer, evaluation system, or specialized integrations. The goal is not to reinvent the entire technology stack. It is to retain control over the parts of the system that make the organization distinct.
Building can make sense when:
- The workflow is strategically critical.
- Proprietary data or institutional knowledge drives performance.
- Commercial tools do not fit the process well.
- The organization needs tighter control over behavior, intellectual property, or roadmap decisions.
- The capability is likely to support multiple future use cases.
The advantages are clear. Building can create control, flexibility, and institutional learning. It may also allow the organization to develop a more tailored system than a general market product can provide.
The burden is equally real. Building requires talent, budget, testing, monitoring, security, documentation, and maintenance. A custom capability can become expensive to update and difficult to govern if it grows faster than internal discipline. Leaders should ask not only whether they can build a solution, but whether they want to own the full responsibility that follows.
Buy when the market is mature and differentiation is limited
Buying is often the best fit when the capability is standardized, rapidly evolving, and not itself the source of competitive distinction. Cloud infrastructure, foundation model access, identity management, security controls, monitoring tools, and general-purpose AI development platforms often fall into this category.
Buying can deliver speed and reduce the need to build commodity capabilities from scratch. It can also provide access to vendor expertise and ongoing product improvements that would be costly to duplicate internally.
Still, buying does not eliminate risk. It can create dependency on a provider’s pricing, uptime, support quality, feature roadmap, and data terms. A product may work well at first but prove difficult to adapt later. Organizations should evaluate:
- Data ownership, retention, use, and deletion terms
- Exit and portability provisions
- Security controls and incident response expectations
- Integration requirements and API limitations
- Evaluation, monitoring, and documentation practices
- Service levels, support structure, and pricing model
- Limits on customization and administrative control
Buying a tool is not the same as transferring accountability. The organization remains responsible for how that tool affects employees, customers, residents, vendors, and other stakeholders.
Partner when expertise and adoption capacity are limited
Partnership becomes valuable when the business problem is clear but internal capacity is not deep enough to manage implementation, integration, change management, training, or specialized oversight. A qualified partner may help with process redesign, security review, evaluation planning, deployment support, and workforce preparation.
The strongest partnerships do more than deliver a technical artifact. They help the organization build internal understanding. Knowledge transfer matters. If a system is too opaque for internal leaders to govern, the organization may gain a vendor dependency without gaining operational maturity.
A responsible partnership should define:
- Scope and decision rights
- Data access boundaries
- Intellectual property terms
- Testing and acceptance criteria
- Security and compliance responsibilities
- Documentation standards
- Training expectations
- Transition, support, and exit plans
Partnership should strengthen internal leadership, not replace it.
A practical framework for deciding build, buy, or partner
Three factors help clarify the decision.
Strategic criticality
How important is the workflow to the organization’s identity, customer relationships, operating model, or future growth? The more strategically critical and proprietary the workflow, the stronger the case for building or co-developing key layers.
Internal capability
Does the organization have the people, data, governance discipline, and operational bandwidth to deliver and maintain the solution responsibly? If not, a partner may be necessary even when the use case is important.
Market maturity
Are there proven products in the market that address the need with acceptable quality and controls? If yes, buying may be more efficient. If not, building or selective partnership may be warranted.
A simple way to think about it is this:
- High criticality plus strong internal capability may support building.
- High criticality plus limited internal capability may support partnering.
- Lower criticality plus a mature vendor market may support buying.
- High criticality plus a mature market may support a blended model where the organization buys the foundation and builds the proprietary workflow layer.
Hypothetical example: property-services invoicing workflow
The following example is hypothetical. It is not MFHC work, not a portfolio-company engagement, and not a client case study.
Imagine a property-services company that handles a high volume of invoices, work orders, vendor records, and approval checks. Staff currently review documents across multiple systems, compare line items against internal policies, confirm service completion, and route exceptions for human review. The process is labor-intensive and slow, especially when records are incomplete.
In this scenario, the company might buy foundational components such as cloud infrastructure, identity controls, secure storage, monitoring tools, and access to a model platform. Those are mature capabilities available in the market.
It might build the business-specific layer that reflects how it actually operates: approval thresholds, vendor categories, exception logic, audit requirements, route-to-review rules, and the internal definitions used by finance and operations. That logic is closer to the organization’s real value.
It might partner with a specialized implementation firm to map the workflow, integrate existing systems, train employees, test failure modes, and document governance procedures.
A responsible deployment would not allow the system to finalize every decision on its own. It might prepare a recommended match, flag missing data, surface unusual charges, and send uncertain cases to a trained employee for review. Success would be measured through processing time, error reduction, escalation rates, employee adoption, and service quality. The lesson is straightforward: buy the common infrastructure, build the differentiating logic, and partner where specialized support improves execution.
Responsible deployment requires governance and human oversight
A promising AI workflow still needs a governance structure strong enough to handle errors, ambiguity, and change. Responsible deployment means planning for uncertainty, not just for the best-case demo.
Organizations should establish:
- Clear human review points for consequential decisions
- Role-based permissions and access controls
- Data minimization and privacy protections
- Security testing and vendor due diligence
- Monitoring for quality drift and unexpected outputs
- Version control and change management
- Audit trails for material actions and overrides
- Escalation paths for unusual or low-confidence cases
- Employee guidance on acceptable use and limitations
Two public resources are especially useful here. The NIST AI Risk Management Framework offers a structured approach to governing, mapping, measuring, and managing AI-related risk. The NIST Generative AI Profile adds considerations specific to generative systems. For workforce-related issues, the U.S. Department of Labor AI principles provide a worker-centered reference point that addresses transparency, privacy, equity, training, and human oversight.
These resources do not make decisions for leadership teams. They do, however, help organizations ask better questions before scale makes mistakes harder to reverse.
Workforce and community impact should be part of the strategy
AI decisions do not affect software alone. They affect jobs, trust, accountability, access to opportunity, and the quality of service delivered to real people. That is why workforce planning and community impact should be discussed at the front end, not after deployment.
Leaders should be prepared to answer practical questions. Which tasks may change first? What skills will employees need? Where is training required? Which decisions must remain human-led? How will the organization explain system limits and escalation paths to workers and stakeholders?
A human-centered approach treats employees as participants in process redesign, not as passive recipients of a tool. It also recognizes that communities may experience the consequences of poor automation through delays, bias, confusion, or reduced service quality. Strong governance protects more than efficiency. It protects trust.
Practical next steps for executives
Leaders do not need to solve everything at once. A measured approach is usually stronger than a dramatic launch.
Consider this sequence:
- Identify one workflow with clear business value
- Map the current process in detail
- Separate rules-based tasks from judgment-heavy decisions
- Evaluate strategic criticality, internal capability, and market maturity
- Decide what to build, what to buy, and where a partner is justified
- Establish governance, review thresholds, and documentation standards
- Train employees before rollout, not after confusion begins
- Pilot with defined metrics and a clear stop-or-scale decision
For organizations that want to explore broader business strategy, governance, and operating discipline, the next step should be informed inquiry, not exaggerated claims. Explore the MFHC Resource Library or contact MFHC for general business information.
Built to grow strong businesses, meaningful partnerships, and lasting community impact. Connect with McFadden Finch Holdings Company today.
McFadden Finch Holdings Company
Vision. Leadership. Lasting Impact.
Lake Merritt Plaza
1999 Harrison Street, 18th Floor
Oakland, CA 94612
(800) 994-9028 | (510) 973-2677
Fax: (800) 210-5252
www.m-fhc.com | info@m-fhc.com
McFadden Finch Holdings Company (MFHC) is a premier holdings and investment management firm dedicated to driving sustainable growth and long-term value. Our mission is to bridge the gap between visionary capital and community-centric development, ensuring tomorrow’s infrastructure meets today’s needs. Through strategic project management and rigorous market analysis, we empower our partners to navigate the complexities of the California economic landscape with confidence and clarity.
Disclaimer: This article is provided for general informational and educational purposes only. It does not constitute legal, financial, investment, tax, accounting, securities, lending, real estate, architectural, engineering, construction, employment, veterinary, medical, nonprofit, philanthropic, public-policy, or other professional advice. Business conditions, regulations, services, programs, costs, funding, investment criteria, and availability may change. Readers should verify current information and consult qualified professionals before acting. References to McFadden-Finch Holdings Company, its subsidiaries, portfolio organizations, affiliated nonprofits, outside organizations, products, services, or resources do not imply a guarantee of engagement, funding, investment, approval, availability, endorsement, partnership, or outcome. Reading an article or submitting an inquiry does not create an advisory, fiduciary, client, funding, investment, or professional relationship.
