Cardinal Group Limits Custom AI Builds to Halt Enterprise SaaS Sprawl

Capital, Code, or Contracts: A Data and AI Executive's Build vs Buy Playbook — Ai4

Ai4

Mid-market companies must replace the build-versus-buy binary with a four-part framework that reserves internal development strictly for proprietary data and fractional needs while commercial platforms handle commoditized operations.

AI-assisted summary of Capital, Code, or Contracts: A Data and AI Executive's Build vs Buy Playbook — original source. Check the original for full context.

Source published: 2026-08-19

Detailed notes

## Background Published on YouTube by the Ai4 channel on August 19, 2026, this session features Rachel Ibarra, VP of Data & Innovation at Cardinal Group Management. The presentation details a tactical 'Build, Buy, Borrow, or Try' decision matrix designed to replace the outdated build-versus-buy binary, helping mid-market enterprise leaders balance internal build capacity against system sprawl and operational risk.

## TL;DR Rachel Ibarra challenges enterprise leaders to move beyond the traditional build-or-buy binary by adopting a four-part framework: Build, Buy, Borrow, or Try. She emphasizes that organizations must achieve 'speed through stability' by prioritizing governed data and managing operational debt before investing in advanced AI or software point solutions. While buying and borrowing fit commoditized business functions, custom building is reserved for proprietary data edges or fractional use cases, as demonstrated by Cardinal Group's custom SOP retrieval bot, 'Stan.' Through stage-gated pilots, organizations can rigorously evaluate 24/7 maintenance burdens and operational feasibility before committing to full-scale rollouts.

## Atmosphere & style The presentation carries a pragmatic, refreshingly candid, and executive tone that demystifies tech-industry hype in favor of operational reality. Ibarra blends sharp corporate realism with wry humor—noting that data governance is an endless battle and developer enthusiasm must be deliberately channeled—drawing directly from her front-line consulting and management experience. It feels like an authentic, clear-eyed tactical debrief rather than a standard vendor pitch, leaving listeners with a grounded sense of strategic discipline.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=4s) Mid-market companies whose core competency is not software development must exercise capital discipline, pairing rich operational data with targeted builds rather than indiscriminate procurement. - [01:38](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=98s) Speed through stability: modern AI and technical velocity depend on reliable, well-governed foundational data infrastructure, analogous to bullet trains requiring rigid tracks. - [01:38](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=98s) Every new software deployment or agentic tool incurs operational debt through process friction, user training, and cultural change management. - [04:07](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=247s) The traditional build vs. buy dichotomy should expand into a four-part decision matrix: Build, Buy, Borrow, or Try. - [04:07](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=247s) Disciplined leadership must restrain developers' natural instinct to build when existing platform modules can be 'borrowed' or standard commoditized workflows can be 'bought'. - [06:52](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=412s) Internal builds should be strictly reserved for proprietary data advantages, unique operational workflows, niche integration bridges, or fractional needs. - [06:52](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=412s) Cardinal Group built 'Stan,' an internal SOP RAG bot, solving a fractional need in-house and avoiding an over-engineered $100k+ annual SaaS expense. - [09:36](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=576s) Low-stakes internal workflows with forgiving failure modes are ideal candidates for custom development, unlike resident-facing tools that demand 24/7 engineering overhead. - [09:36](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=576s) Stage-gated 'Try' cycles derisk technology investments by validating operational burdens and true utility before committing to multi-year contracts or full production builds. - [11:28](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=688s) Building in-house should aim for strategic advantage rather than mere initial cost savings, as all custom software creates ongoing maintenance and support debt. - [11:28](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=688s) Failed internal experiments during 'Try' cycles still yield transferable organizational learnings and technical capabilities for future projects. - [15:05](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=905s) Data governance serves as the indispensable foundation for innovation; without clean, structured pipelines, advanced AI and ML initiatives cannot succeed.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=4s) The Mid-Market Reality and the Innovation Challenge

Rachel Ibarra opens by drawing from her background across diverse enterprise environments, having led data teams and worked as an IT management consultant where she witnessed "the good, the bad and the ugly—very ugly." At Cardinal Group Companies, a vertically integrated mid-market real estate organization managing over 200 properties, the core value proposition centers entirely on property management and resident experience rather than software engineering.

This operational focus creates a distinct strategic challenge: how does a non-tech mid-market company innovate and establish competitive differentiators without recklessly burning capital or buying off-the-shelf software indiscriminately? Cardinal Group navigates this by pairing years of rich, transactional property management system (PMS) data with a lean, highly capable internal data team tasked with executing targeted custom builds.

- **Scale of Operations:** Over 200 properties under management in a vertically integrated structure. - **Core Competency:** Property management and resident experience, not commercial software development. - **Strategic Goal:** Drive innovation and competitive differentiation while exercising rigorous capital discipline.

---

[01:38](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=98s) Foundational Technology, Operational Debt, and Speed Through Stability

Before adopting any new technology, leaders must ground their strategy in current organizational capability. Foundational technology is not merely having core HR or finance applications; it requires governed, trustworthy data. As Ibarra quips, "data governance is an adventure that I think we will fight until the end of time," but organizations starting from spreadsheets must take a fundamentally different implementation route than those with mature data warehouses. Point solutions pitched by vendors must be weighed against where an organization actually stands today.

```mermaid flowchart TD accTitle: Speed Through Stability Model subgraph Foundation["1. Foundational Stability"] A["Governed Data Assets"] --> B["Core Enterprise Infrastructure"] end subgraph Velocity["2. Controlled Velocity"] B --> C["Bullet Train Infrastructure"] C --> D["Rapid Innovation & AI Workflows"] end subgraph Debt["3. Friction Management"] D --> E["Operational Debt Mitigation"] D --> F["Data Silo Prevention"] end ```

To illustrate sustainable growth, Ibarra uses the metaphor of high-speed bullet trains: they travel at extreme speeds only because they run on rigid, reliable infrastructure designed to prevent catastrophic failures—a concept she terms "speed through stability." Every new software tool, agentic workflow, or data feed introduces "operational debt," encompassing process overhauls, training, and inevitable cultural change resistance. Furthermore, uncoordinated point solutions risk spawning isolated data silos unless deliberately designed into a cohesive operating ecosystem.

- **Operational Debt:** The hidden organizational overhead of process friction, change management, and user resistance that accompanies any new deployment. - **Data Silo Risk:** Point solutions bought in isolation fragment the enterprise data picture unless actively integrated. - **Execution Reality:** Advanced AI ambitions must match the foundational maturity of the organization's existing data infrastructure.

---

[04:07](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=247s) Expanding the Matrix: Build, Buy, Borrow, or Try

Ibarra reframes the traditional build-versus-buy binary into a four-part decision matrix: **Build, Buy, Borrow, or Try**. Choosing between borrowing and buying requires immense leadership discipline because "developers love to develop. Engineers want to engineer." If asked, technical staff will almost always say yes to building something new, even when building is commercially irrational.

```mermaid flowchart TD accTitle: Build Buy Borrow or Try Decision Flowchart Start["New Capability Needed"] --> Standard{"Standard or Commodity Function?"}

Standard -- Yes --> ExistingMod{"Module in Existing Platform?"} ExistingMod -- Yes --> Borrow["BORROW: Turn on existing module / await roadmap"] ExistingMod -- No --> Buy["BUY: Procure proven commercial point solution"]

Standard -- No --> Advantage{"Proprietary Data or Edge?"} Advantage -- Yes --> HighStakes{"High Stakes / Resident Facing?"} HighStakes -- Yes --> Try["TRY: Run stage-gated pilot & assess 24/7 overhead"] HighStakes -- No --> Build["BUILD: Develop custom internal microservice / tool"] Advantage -- No --> Borrow ```

"Borrowing" means leveraging dormant capabilities within existing, deeply integrated platforms—such as activating an add-on module in an HRIS, CRM, or ERP, or waiting for a vendor roadmap update rather than buying a separate point tool. "Buying" should remain the default for commoditized industry workflows. In property management, functions like leasing workflows, maintenance tracking, tour scheduling, and lead capture already have mature market solutions, meaning custom software development rarely justifies the capital expense.

- **Borrow:** Maximize existing contracts and platform modules before adding new vendors to the stack. - **Buy:** Standardize on commercial platforms for non-differentiating operational functions (e.g., HR, accounting, basic CRM). - **Discipline Imperative:** Curb internal engineering enthusiasm when off-the-shelf or roadmap options are "good enough."

---

[06:52](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=412s) Strategic Building and the Story of "Stan" the RAG Agent

Internal software development must be reserved for specific strategic opportunities: proprietary data advantages, unique operational efficiencies, niche integration gaps, or fractional requirements. Niche needs often arise when bridging legacy infrastructure with modern tools; rather than purchasing expensive, rigid middleware, an internal team can write a lightweight microservice.

Ibarra shares the example of Cardinal Group's internal RAG agent named "Stan"—affectionately named because he holds their Standard Operating Procedures. In property management, employees constantly navigate massive volumes of policies, handbooks, and operational guides. Multiple enterprise vendors pitched comprehensive AI-driven employee experience platforms costing approximately $10 per user per month, totaling more than $100,000 annually. Because Cardinal only required a low-stakes internal question-answering tool, building Stan in-house solved the fractional problem at a fraction of the commercial cost without paying for unnecessary enterprise bloat.

- **The "Stan" Bot:** An in-house retrieval-augmented generation (RAG) assistant answering internal employee questions regarding policies and standard operating procedures. - **Cost Avoidance:** Prevented a $100,000+ recurring annual SaaS spend for an over-engineered employee portal. - **Low-Stakes Advantage:** Internal tools with forgiving failure modes represent prime candidates for custom in-house builds.

---

[09:36](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=576s) De-Risking Innovation Through Stage-Gated "Try" Cycles

The "Try" pillar serves as an active risk-mitigation strategy for both build and buy initiatives. To validate return on investment and technical feasibility, Cardinal Group implements strict stage gates and success metrics before committing to full-scale internal builds or commercial vendor contracts.

A critical consideration during the "Try" phase is understanding the true maintenance and operational reality of a deployment. For non-critical internal software, downtime is manageable; however, any customer-facing application interacting directly with property residents demands around-the-clock operational readiness. If a resident-facing system fails, it instantly turns into an "all hands on deck, stop everything, 24/7" engineering emergency. Stage-gated pilots expose these support overheads before the organization locks itself into unsustainable maintenance burdens.

- **Stage-Gating:** Defining strict key performance indicators (KPIs) and operational criteria before advancing a pilot to production. - **Support Overhead Assessment:** Calculating whether internal engineering can realistically provide 24/7 operational support for customer-facing systems. - **Vendor Pilots:** Testing vendor claims in real-world workflows to confirm practical utility prior to multi-year contractual commitments.

---

[11:28](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=688s) The Monday Morning Playbook for Ecosystem Governance

Ibarra provides a five-step playbook for data and AI leaders navigating architectural decisions:

1. **Anchor in Reality:** Acknowledge organizational identity. Non-technical mid-market enterprises cannot evaluate their tech footprint through the lens of a Silicon Valley software company: "Extraordinary looks different." 2. **Audit First:** Thoroughly evaluate existing software and vendor roadmaps before entertaining vendor pitches for agentic tools. Conserve organizational change tolerance for high-impact gaps. 3. **Build for Advantage, Not Just Cost Savings:** Discard the naive assumption that building is simply cheaper. Every build incurs costs via ongoing personnel, change management, bug fixes, and support. Build only where it yields real operational or strategic leverage. 4. **Weaponize "Try":** Run ruthless experiments on fractional and niche needs. Even when internal experiments fail to reach production and the company elects to buy, the foundational learning and engineering skills are repurposed into subsequent successful projects. 5. **Govern an Ecosystem:** Treat technology, data assets, and operational workflows as an interconnected ecosystem. Prioritize sustainable velocity through stable, well-governed infrastructure.

---

[15:05](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=905s) Q&A: Unifying Data and Innovation Under One Umbrella

When asked how she manages the intersection between her dual responsibilities as VP of Data and VP of Innovation, Ibarra highlights data governance as the foundational prerequisite for any modern technical initiative.

Innovation cannot exist in a vacuum disconnected from underlying data realities. Whether an organization plans to launch generative AI agents, machine learning forecasting models, or modernized business intelligence reporting, the initiatives will inevitably stall without clean, governed, and structured data pipelines. Unifying data and innovation ensures that technical ambition remains tethered to operational viability.

## Notable quotes > [00:04](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=4s) the good, the bad and the ugly—very ugly — Rachel Ibarra

> [01:38](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=98s) data governance is an adventure that I think we will fight until the end of time — Rachel Ibarra

> [04:07](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=247s) developers love to develop. Engineers want to engineer. — Rachel Ibarra

> [09:36](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=576s) all hands on deck, stop everything, 24/7 — Rachel Ibarra

> [11:28](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=688s) Extraordinary looks different. — Rachel Ibarra

## Mentioned Ai4, Cardinal Group Companies, Cardinal Group Management, Rachel Ibarra, Stan

## Video description Rachel Ibarra - VP of Data & Innovation, Cardinal Group Management

The traditional "Build vs. Buy" dilemma is an outdated binary that limits how enterprise leaders actually drive value. As a Data and AI executive at a mid-market enterprise, I know firsthand that we must carefully balance our internal build capacity against the risks of system sprawl to architect a cohesive, governed ecosystem. In this session, I will explain how to move beyond this binary choice using a tactical "Build, Buy, Borrow, or Try" decision matrix. I will illustrate when you should leverage internal engineering versus when you should maximize efficiency and minimize risk by extending existing platforms or utilizing agile pilots. Join me to walk away with a practical framework for making tech investments that prioritize operational efficiency and improved decision-making above all else.

[Source](https://www.youtube.com/watch?v=1AKJ8JJL_CM)

中文简报

Cardinal Group限制定制AI开发以遏制企业SaaS蔓延中型企业必须用四维决策框架取代非建即买的二元模式，将内部开发严格限定于专有数据和碎片化需求，由商业平台处理通用化业务。 Rachel Ibarra呼吁企业领导者跳出传统的“自建或采购”二元对立，采纳包含自建（Build）、采购（Buy）、借用（Borrow）或试用（Try）的四维框架。她强调，组织在投资尖端AI或单点软件方案前，必须通过优先推进数据治理和管控运营负债来实现“稳中求快”。虽然采购和借用适用于通用业务功能，但定制开发应仅保留给专有数据优势或碎片化应用场景，正如Cardinal Group定制的SOP检索机器人“Stan”所展示的那样。通过分阶段的试点评估，组织能够在正式全面推广前，严格衡量全天候维护负担与运营可行性。核心竞争力不在软件开发的中型企业必须恪守资本纪律，将丰富的运营数据与针对性的自建相结合，而非盲目采购。 (0:04) 稳中求快：现代AI与技术迭代速度依赖于可靠且治理完善的基础数据设施，犹如高铁离不开坚固的轨道支撑。 (1:38) 每一次新软件的部署或智能体工具的引入，都会因流程摩擦、用户培训和组织文化变革管理而带来运营负债。 (1:38) 传统的“自建与采购”二元划分应拓展为四维决策矩阵：自建、采购、借用或试用。 (4:07) 当现有平台模块可以直接“借用”，或标准通用的工作流可以直接“采购”时，务实的领导层必须克制技术团队自建系统的本能冲动。 (4:07)

Reading summary

Rachel Ibarra of Cardinal Group Companies argues that mid-market enterprises must balance innovation with capital discipline by expanding the conventional build-versus-buy binary into a four-part framework: Build, Buy, Borrow, or Try. Grounding Innovation in Data and Operational Debt (0:04) Non-technical mid-market enterprises cannot operate like Silicon Valley software firms. At Cardinal Group Companies, which manages more than 200 properties, the primary business focus remains property management and resident experience rather than software engineering. To innovate responsibly without exhausting capital, organizations must first ground their initiatives in clean, governed data rather than pursuing disconnected point solutions. Speed Through Stability and Operational Friction (1:38) Ibarra uses the metaphor of high-speed bullet trains to argue that rapid technical velocity is possible only when supported by stable, reliable foundational infrastructure. Adopting new applications, data feeds, or agentic workflows introduces operational debt, which manifests as workflow disruptions, training overhead, and cultural resistance to change. Without deliberate architectural integration, isolated software tools risk creating fragmented data silos. The Four-Part Matrix: Build, Buy, Borrow, or Try (4:07) To counter the engineering tendency to build custom software unnecessarily, leaders should evaluate requirements across four options. Buying serves as the default for commoditized industry functions such as leasing workflows, maintenance tracking, and payroll. Borrowing involves activating dormant features in existing enterprise platforms or waiting for vendor roadmap updates before taking on new software contracts. Strategic Custom Builds for Fractional Needs (6:52) Custom internal engineering should be reserved for proprietary data assets, unique workflows, or niche integration gaps where commercial software is over-engineered. As an example, Cardinal Group avoided a recurring annual software-as-a-service cost exceeding $100,000—quoted by vendors at roughly $10 per user monthly—by building 'Stan,' an internal retrieval-augmented generation agent that answers employee questions on standard operating procedures at a fraction of the cost. De-Risking Deployments Through Stage-Gated Pilots (9:36) The 'Try' mechanism acts as a risk-mitigation step before committing capital to vendors or initiating full-scale internal builds. Stage-gated pilots allow organizations to evaluate actual return on investment and assess maintenance realities. For example, while internal tools can tolerate occasional downtime, customer-facing systems for property residents require 24/7 engineering readiness, which introduces significant ongoing support overhead. Ibarra concludes that uniting data governance and innovation under a single strategy ensures technical experimentation remains anchored in operational reality, though she notes that maintaining data governance remains a persistent, ongoing operational challenge.

精炼阅读摘要

Cardinal Group Companies 数据与创新副总裁 Rachel Ibarra 指出，非科技属性的中型企业在推动数据与人工智能应用时，必须跳出“自建还是外购”的二元对立思维，转而采用涵盖“自建、外购、借用与试点”（Build, Buy, Borrow, or Try）的四维决策框架，以受治理的数据资产和底层稳定性作为创新的首要基石。中型企业现实与以稳求快的底层治理 (1:38) Cardinal Group 是一家管理着超过 200 处物业的垂直整合型房地产企业，其核心业务在于物业管理与住户体验，而非商业软件研发。Ibarra 认为，非科技中型企业面临的独特挑战，在于如何在不挥霍资本和不盲目采购现成软件的前提下构建竞争壁垒。脱离现实基础盲目引入单点工具，极易产生由流程重组、人员培训及文化抗拒构成的“运维负债”（Operational Debt），并加剧数据孤岛风险。为此，Ibarra 提出了“以稳求快”（Speed Through Stability）的理念，并以高铁作为隐喻：高铁能维持极高速度运行，根本上依托于坚固可靠的轨道基建。企业在探索前沿的人工智能或自动化流程前，必须以真实的数据治理为根基。对于从电子表格起步的企业与拥有成熟数据仓库的企业，实施路径存在本质差异，技术规划必须与现有数据基础设施的成熟度严格对齐。四维决策矩阵中的借用与外购纪律 (4:07) Ibarra 强调，技术人员出于本能往往热衷于自主开发，管理层必须具备强大的战略定力来遏制这种非理性的自建冲动，在通用需求上优先实行“借用”（Borrow）与“外购”（Buy）。“借用”是指优先挖掘 HRIS、CRM 或 ERP 等现有深度集成平台中闲置的附加模块，或等待厂商的产品路线图更新，以避免盲目扩充供应商数量。针对商品化的非差异化流程，“外购”应当成为默认选项。在物业管理领域，租赁工作流、维保工单追踪、预约看房及线索捕获等环节，市场上均已具备成熟的商业化软件。在这类缺乏专有优势的标准化功能上投入工程团队进行定制开发，在商业与财务逻辑上很难证明其资本支出的合理性。战略自建的触发场景与轻量化智能体 (6:52) 自主代码开发（Build）必须严格限制在具备战略杠杆的少数场景：利用数十年专有数据驱动分析预测、构建独特的跨部门运营流程、开发轻量微服务以填补老旧系统的集成缝隙，以及应对商业软件功能冗余的轻量化需求。 Cardinal Group 自主构建的内部知识检索智能体“Stan”提供了典型范本。该工具以收录标准作业程序（SOP）为名，旨在协助员工快速检索海量运营规范。多家供应商曾推销全套企业级员工门户方案，报价达到每人每月约 10 美元、年费逾 10 万美元。由于该场景属于低容错风险的内部问答需求，团队通过自建轻量检索增强生成（RAG）微服务，以极低成本解决了实际痛点，成功规避了每年超过 10 万美元的冗余 SaaS 软件开销。以阶段门控试点化解全天候运维风险 (9:36) “试点”（Try）是防范自建与外购双重风险的关键机制。Cardinal Group 采用严格的阶段门控（Stage-Gated）与量化 KPI，在正式投产自主系统或签订多年期商业合同前验证投资回报率与可行性。试点不仅能够检验厂商承诺的真实价值，更能前置暴露系统后续的实际运维成本。 Ibarra 特别指出，不同软件类型的运维压力截然不同。内部辅助工具发生偶发性故障通常尚在可接受范围内；但一旦涉及直接面向物业住户的交互系统，任何停机都会演变为要求工程团队“全员上阵、全天候 24/7 待命”的严重紧急事件。阶段门控试点能迫使团队在决策早期审视自身是否具备全天候维护能力，避免企业背上无法承受的长期支持包袱。五步生态治理准则与数据同创新的统合 (11:28) Ibarra 为技术领导者梳理了五步生态治理准则：首先立足现实，清醒认识到非科技企业不应以硅谷软件公司的标准来衡量卓越；其次前置审计，在接纳新工具前全面评估现有系统与供应商路线图，节约组织的变革承受力；第三，为了构建业务杠杆而非单纯节省账面成本而自建，将后续维护与排错代价纳入核算；第四，将试点作为敏捷试错工具，即便实验未投产，所沉淀的技术能力亦可迁移至后续项目；第五，将技术、数据与工作流视为有机生态进行全局治理。针对兼任数据副总裁与创新副总裁的职责协同，Ibarra 强调数据治理是任何技术创新的核心前提。无论是生成式 AI 智能体还是机器学习模型，若脱离了干净、受治理且结构化的数据流水线，创新规划都将难以持续落地。 Ibarra 阐明了非科技属性的中型企业通过严格治理与资本纪律实现技术突围的可行路径，但该模式的有效落地高度依赖于组织对自身运维边界与数据成熟度的清醒研判。在面临兼具高度定制化与全天候高可用性要求的混合业务场景时，内部轻量开发与外部专业支持之间的责任界线，仍需要在实践中动态评估。

Detailed notes — zh

## Background 该内容由 Ai4 于 2026 年 8 月 19 日发布在 YouTube 平台。视频记录了 Cardinal Group Management 数据与创新副总裁 Rachel Ibarra 的演讲，核心探讨中端企业如何突破传统“自研还是外购”的二元对立困境，通过构建“自研、外购、借用或试用”的决策矩阵来平衡自研产能与系统蔓延风险，从而实现高效稳健的数字化投资。 ## TL;DR 演讲系统拆解了非科技中端企业在数字化转型中的技术投资逻辑，提出了升级版的“自研、外购、借用或试用（Build, Buy, Borrow, or Try）”四维决策框架。Rachel 强调企业必须警惕引入单点工具带来的“运营债务”与数据孤岛，秉持“以稳定性换取速度”的原则，仅在拥有专有数据优势、独特运营壁垒或碎片化利基场景下开展轻量自研（如内部 SOP 智能体“Stan”）。对于成熟通用功能应果断外购，对现有大系统未激活模块要充分“借用”，并借助严苛的阶段关卡进行“试用”以降低创新试错成本。 ## Atmosphere & style 整体基调务实清醒、直击痛点且极具实操指导性。Rachel 凭借跨越咨询与企业甲方的丰富实战经历，以生动贴切的比喻（如高铁运行的轨道基础设施）和风趣幽默的语言，深刻拆解了工程师盲目自研的冲动与外部厂商的营销泡沫，整场分享节奏明快、言之有物，让听众在接地气的案例复盘中收获清晰的决策清醒感与行动框架。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=4s) 中端非科技企业应立足自身业务现实，在技术非核心收入来源的前提下，利用沉淀的专有业务数据与精干团队打造差异化壁垒。 - [01:38](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=98s) 引入任何新工具、新 Agent 或数据源都会带来“运营债务”，企业的技术落地路径必须根据底层数据治理成熟度量身定制。 - [01:38](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=98s) 践行“通过稳定性实现速度”理念，依靠坚实的基础设施和容错护栏降低变革阻力，防止单点工具滋生数据孤岛。 - [04:07](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=247s) 打破传统“自研与外购”的二元对立，升级为涵盖自研、外购、借用与试用（Build, Buy, Borrow, or Try）的四象限决策框架。 - [04:07](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=247s) “借用”与“外购”本质上是对工程团队开发冲动的约束，应优先启用现有大系统的内置功能或直接采购行业通用标准方案。 - [06:44](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=404s) 自研（Build）决策应严格受限于四大场景：专有数据优势、独特运营流程、新旧系统利基集成以及分片碎片化需求。 - [06:44](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=404s) Cardinal 自研内部 RAG 智能体“Stan”以极低成本满足 SOP 查询需求，成功避免了外部重型方案每年超 10 万美元的冗余采购费用。 - [09:36](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=576s) 引入“阶段关卡（Stage Gates）”与试用机制为创新去风险化，在小范围试点中提前核算 7x24 小时运维现实与系统故障代价。 - [09:36](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=576s) 管理层应坚持“立足现实”与“购买前先审计”，切忌盲目跟风供应商演示而盲目采购号称全能的 AI 单点工具。 - [12:49](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=769s) 自研资产绝非免费，免去软件许可费的同时必然会以全天候运维、人力编制与变革管理等隐性成本兑现，因此自研必须针对核心壁垒。 - [13:28](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=808s) 将“试用”武器化并建立实验复利机制，即使概念验证最终转为外部采购，过程中积累的底层技术认知仍能反哺后续核心自研项目。 - [14:58](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=898s) 高质量数据与稳健的数据治理是所有 AI、机器学习及前沿创新能够落地生根的必要基石，脱离数据底座的技术探索终成空中楼阁。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=4s) 中端市场的现实：非科技企业的创新平衡演讲者 Rachel Ibarra 开场介绍了自己的背景。在担任 Cardinal Group Management 的数据与创新副总裁之前，她曾领导过另一家机构的数据团队，更早之前则是一名 IT 管理顾问。多年的从业经历让她亲眼见识了各类型企业在技术实践中的“好的、坏的，以及非常丑陋的一面”，而今天分享的决策框架正是这些经验的总结与融合。 Rachel 指出，讨论技术策略必须立足于“中端市场（Mid-market）的现实”。Cardinal Group 是一家垂直整合的物业管理公司，目前旗下管理着超过 200 处物业资产。公司的核心价值在于物业管理与住户体验，而非软件开发或技术本身。然而，这并不意味着公司对技术采纳采取消极态度——“我们可不会直接说‘哦，反正我们不做这个，那就随便买点现成软件看看效果吧’”。依靠物业管理系统中沉淀多年的交易数据，加上 Rachel 带领的一支“精简却极其强悍”的小团队进行部分定制开发，企业面临的核心问题是：如何在明智花钱的同时，打造出具备竞争壁垒的差异化创新。 ```mermaid flowchart TD accTitle: Cardinal Group 的中端市场技术定位 subgraph Core["核心业务根基"] A["200+ 处在管物业资产"] B["多年核心交易数据沉淀"] C["垂直整合与住户体验为核心"] end subgraph Challenge["核心挑战与目标"] D["避免盲目外购与系统蔓延"] E["精干团队聚焦定制化创新"] F["打造差异化壁垒与合理控制成本"] end A --> D B --> E C --> F ``` - **公司规模**：管理超过 200 处物业资产，具备垂直整合运营能力。 - **核心业务定位**：住户体验与物业资产运营，技术作为使能工具而非直接营收产品。 - **团队形态**：规模虽小但作战能力极强的定制开发与数据团队。 --- ### [01:38](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=98s) 稳中求快：警惕技术引入带来的“运营债务” 在深入决策模型前，企业必须正视自身的现实能力。Rachel 强调，企业当前的基础能力决定了其战略路线。所谓“基础设施”，不仅指是否拥有 HR 或财务系统，更重要的是系统中的数据是否受到治理——尽管她笑着调侃“数据治理是一场我们可能会战斗到世界末日的冒险”。如果企业目前的数据管理还停留在电子表格阶段，并非代表无法前行，而是其落地的路径必须完全不同。面对市场上无数推销“无所不能”方案的供应商，企业首先要清醒评估现状。引入任何新系统、新 Agent 或新数据源，企业实际上都是在背负“运营债务（Operational Debt）”。Rachel 提出了“通过稳定性实现速度（Speed through stability）”的理念，并以高速列车打比方：高铁之所以能飞速行驶，是因为有极其坚固的基础设施护航，避免灾难性事故。技术的引入必然伴随着业务流程的重构、员工认知调整、变革管理（Change management）以及不可避免的阻力。此外，每一个单点工具（Point Solution）的引入都会制造新的数据孤岛。因此，评估技术选型时，不能只看技术堆栈本身，更要看整个组织运营生态的连贯性。 --- ### [04:07](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=247s) 决策矩阵之“借”与“买”：克制开发冲动与拥抱标准能力为了打破“自研还是外购（Build vs. Buy）”这种非黑即白的二元对立，Rachel 提出了升级版的 **“自研、外购、借用或试用（Build, Buy, Borrow, or Try）”** 四象限决策矩阵。她指出，选择“借用”或“外购”本质上是对工程团队的一种“纪律约束”。因为“开发者天生热爱开发，工程师总是渴望工程实现”，当你询问开发人员能否做某个功能时，他们几乎从不会说“不”，而是跃跃欲试去尝试新鲜事物，但这并不意味着企业应该去自研。 ```mermaid flowchart LR accTitle: 四维技术决策矩阵 subgraph Retain["控制与整合"] A["Borrow 借用 启用现有系统未激活模块"] B["Buy 外购 成熟标准功能与行业通用工具"] end subgraph Innovate["创新与探索"] C["Build 自研 专有数据/运营优势/分片需求"] D["Try 试用 阶段关卡验证 ROI 与维护成本"] end A --- B C --- D ``` 针对“借用（Borrow）”，核心在于深度利用已集成的大型企业系统（如 HR、CRM、营销或财务系统）中尚未开启的内置模块，或者等待其产品路线图的更新。即便市面上有众多令人眼花缭乱的单点解决方案，企业也应克制冲动，认真审视现有模块是否“已经足够好用”，有时耐心等待能换来巨大的系统整合效益。而在“外购（Buy）”方面，应坚定应用于行业标准化功能（如租赁管理、工单维护、线索获取、看房预约等通用环节）。在中端市场有限的资本与研发带宽下，绝无必要在每个通用领域都去“重复造轮子”。 --- ### [06:44](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=404s) 决策矩阵之“自研”：专有数据优势与“Stan”轻量智能体案例谈到“自研（Build）”时，Rachel 归纳了四大核心适用场景： 1. **专有数据优势（Proprietary Data Advantage）**：拥有多年积累的高质量数据，可用于训练专属机器学习模型，或通过数据仓库打通多源数据讲出全新业务故事； 2. **独特运营优势（Operational Advantage）**：涉及跨系统、跨团队数据流转的特殊 Agent 自动化工作流与内部提效； 3. **利基/过渡需求（Niche Need）**：新旧系统打通时的定制化集成。例如为了将陈旧的财务系统与现代化新系统对接，与其购买极其昂贵且仍需繁琐适配的中间件，不如自研一个轻量微服务快速解决； 4. **分片/碎片化需求（Fractional Need）**：仅需满足特定单一环节，无需为庞大软件全家桶买单。 ```mermaid flowchart TD accTitle: 自研决策四要素 A["自研 (Build) 适用场景"] A --> B["专有数据优势 长期业务数据与专属 ML 模型"] A --> C["独特运营优势 跨部门定制 Agent 工作流"] A --> D["利基集成需求 连接新旧系统的轻量微服务"] A --> E["分片特定需求 聚焦低风险内部单点场景"] ``` 关于分片需求，Rachel 分享了 Cardinal 内部打造的 RAG 智能体案例。由于汇集了海量标准作业程序（SOP），团队给这个智能体取名为“Stan”（取自 **S**tandard **O**perating Procedures 的谐音），专门用于解答员工关于政策制度、操作指南和员工手册的日常咨询。曾有三家外部供应商向她推销涵盖员工体验与内容管理的 AI 解决方案，报价约为每人每月 10 美元。若按全员规模计算，年采购成本将超过 10 万美元。虽然供应商产品功能更丰富，但公司根本不需要多余功能，自研一个低风险的内部小工具不仅成本极低，而且完全满足实际需求。 - **自研 Stan 智能体**：基于 RAG 技术构建的内部知识库助手，精准解答物业 SOP、操作指引与员工手册。 - **成本对比**：拒绝了三家外部厂商每人每月约 10 美元（年费超 10 万美元）的重型方案，采用轻量自研大幅节省开支。 --- ### [09:36](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=576s) 决策矩阵之“试用”与周一行动指南：用阶段关卡化解创新风险矩阵中的第四个维度是“试用（Try）”，其核心目标是“为创新去风险化”。面对自研 ROI 是否划算、外部采购是否真正必要的疑问，Cardinal 引入了类似“阶段关卡（Stage Gates）”的管理机制。在正式铺开前，团队会为试点设定清晰的成功指标与 KPI，并借此充分评估后期的真实运维现实（Maintenance Reality）。 Rachel 强调，运维现实不仅关乎日常系统维护的人力消耗，更关乎故障时的业务代价。例如，任何直接面向住户的自研应用一旦发生宕机，就意味着技术团队必须“全员上阵（All hands on deck）”，提供 7x24 小时的紧急技术支持。通过“试用”机制（包括自研内部小范围验证与采购前的供应商 POC 试点），团队能在低风险环境下看清技术可行性、商业回报与潜在责任。在最后的“周一行动指南（Monday Morning Playbook）”中，Rachel 建议管理层在回归工作时落实两项原则： 1. **立足现实（Anchor in Reality）**：不要被外界铺天盖地的“构建纯 AI 驱动型企业”的宣传冲昏头脑。对于技术非核心收入来源的中端非科技企业，“卓越”的定义截然不同； 2. **购买前先审计（Audit First）**：面对供应商五花八门的“Agentic HR”、“Agentic 财务”演示，首先必须审查内部真实需求与现有资产，切忌盲目跟风采购。 ### [12:49](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=769s) 为竞争优势而构建并审视真实成本在权衡技术自研时，团队必须将宝贵的工程能力和不可避免的“运维负债”（Operational Debt）留给真正核心的业务场景，如果某项功能已经存在于现有工具中或处于供应商的路线图上，就不应盲目重新造轮子。针对业界常说的“自研可以省下巨额采购费用”这一论点，企业决策者必须保持清醒并严加拷问：自研带来的所谓优势究竟是什么？因为在现实中，任何技术资产都绝非免费，企业无论如何都会付出代价——即使没有直接向软件供应商支付采购合同款，也会以人力资源、7×24 小时全天候运维支持、组织变革管理（Change Management）以及客户成功支持等隐性成本的形式支付账单。 - 自研的核心前提是创造真正的差异化竞争优势，而非单纯追求表面上的节省预算。 - 隐性自研成本涵盖全天候技术支持、人员编制、变革管理流程以及后续长期的系统维护负担。 ### [13:28](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=808s) 将“尝试”（Try）武器化与构建实验复利企业应当学会“将‘尝试’（Try）武器化”，这意味着在评估技术方案时，必须以近乎冷酷的严苛标准来定义投资回报率（ROI）、局部碎片化需求（Fractional Need）以及细分利基场景（Niche）。轻量化的试验不仅是验证内部自研能力的试金石，更是判断某项技术是否值得大规模投资的关键关口。即使某些探索性实验最终未能成功进入生产环境，企业转而选择外部采购，这些前期的概念验证也绝非沉没成本。工程团队在实验过程中积累的技术认知与底层基础工作，往往能够沉淀为宝贵的组织资产，并在后续其他成功上线的生产级项目中发挥巨大价值。 ```mermaid flowchart TD accTitle: 试验到落地的价值转化模型 subgraph S1["概念验证与尝试阶段"] A["界定真实 ROI 与利基需求"] --> B["轻量化原型试验 (Try)"] end subgraph S2["决策分流与沉淀"] B --> C{"是否投入生产？"} C -- "是" --> D["内部自研上线"] C -- "否" --> E["转向商业采购 (Buy)"] E -. "沉淀底层技术经验".-> F["赋能其他自研创新项目"] end ``` - 严苛界定组织内部的 ROI、碎片化诉求与特定场景边界，杜绝盲目立项。 - 即使试错项目最终走向外部采购，研发团队积累的底层经验也能反哺后续的核心自研系统。 ### [14:20](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=860s) 统筹治理生态系统：在稳健中寻求敏捷技术管理者本质上是在治理一个庞大且复杂的生态系统，这既包括底层数据与互联互通的技术架构，也包括企业自身的业务运转体系。在引入任何新工具或自研组件时，领导者必须明确知晓自己是否在不经意间制造了新的数据孤岛或堆积了运维负债，所有决策都应在清醒的认知下进行。实现敏捷创新的核心在于“依托稳定性获得速度”（Speed through stability）。在探索过程中，架构体系可以存在一定程度的波动和探索空间，但必须建立坚固的底层基础设施与治理护栏，确保整体业务列车绝不会彻底脱轨。 - 技术选型与自研决策必须统筹考虑整体数据架构，严控数据孤岛与运维负债的蔓延。 - 依托坚固的基础治理框架构建容错护栏，在确保系统不失控的前提下最大化创新与交付速度。 ### [14:58](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=898s) 问答环节：兼顾数据底座与业务创新的共生关系在现场问答中，有参会者提问身兼“数据”（Data）与“创新”（Innovation）两大不同职责的异同与融合之道。数据是所有前沿创新能够落地生根的基石，无论是构建人工智能（AI）、机器学习（ML），还是部署先进的商业智能（BI）与全新业务系统，若缺乏扎实的数据质量与完善的数据治理机制，任何上层创新都会沦为空中楼阁。将数据与创新两个职能统筹在同一阵线下，正是为了确保前沿技术探索与底层数据现实紧密咬合，让所有新兴系统不仅能顺利落地，更能长期稳健高效地运转。 > “数据必须是一切事物的基石。如果你打算构建 AI、机器学习，甚至是我们的 BI 和全新系统，倘若没有高质量的数据和良好的数据治理，你能做的事情就非常有限。” ## Notable quotes > [00:04](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=4s) 我们可不会直接说‘哦，反正我们不做这个，那就随便买点现成软件看看效果吧’ — Rachel Ibarra > [01:38](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=98s) 数据治理是一场我们可能会战斗到世界末日的冒险 — Rachel Ibarra > [01:38](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=98s) 通过稳定性实现速度（Speed through stability） — Rachel Ibarra > [04:07](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=247s) 开发者天生热爱开发，工程师总是渴望工程实现 — Rachel Ibarra > [09:36](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=576s) 为创新去风险化 — Rachel Ibarra > [09:36](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=576s) 立足现实（Anchor in Reality） — Rachel Ibarra > [09:36](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=576s) 购买前先审计（Audit First） — Rachel Ibarra > [13:28](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=808s) 将‘尝试’（Try）武器化 — Rachel Ibarra > [14:58](https://www.youtube.com/watch?v=1AKJ8JJL_CM&t=898s) 数据必须是一切事物的基石。如果你打算构建 AI、机器学习，甚至是我们的 BI 和全新系统，倘若没有高质量的数据和良好的数据治理，你能做的事情就非常有限。 — Rachel Ibarra ## Mentioned Rachel Ibarra, Cardinal Group Management, Ai4, Stan, RAG, Agentic HR, BI, ML ## Video description Rachel Ibarra - VP of Data & Innovation, Cardinal Group Management The traditional "Build vs. Buy" dilemma is an outdated binary that limits how enterprise leaders actually drive value. As a Data and AI executive at a mid-market enterprise, I know firsthand that we must carefully balance our internal build capacity against the risks of system sprawl to architect a cohesive, governed ecosystem. In this session, I will explain how to move beyond this binary choice using a tactical "Build, Buy, Borrow, or Try" decision matrix. I will illustrate when you should leverage internal engineering versus when you should maximize efficiency and minimize risk by extending existing platforms or utilizing agile pilots. Join me to walk away with a practical framework for making tech investments that prioritize operational efficiency and improved decision-making above all else. [Source](https://www.youtube.com/watch?v=1AKJ8JJL_CM)

Source quotes

[0:04] Rachel Ibarra: 我们可不会直接说‘哦，反正我们不做这个，那就随便买点现成软件看看效果吧’ [1:38] Rachel Ibarra: 数据治理是一场我们可能会战斗到世界末日的冒险 [1:38] Rachel Ibarra: 通过稳定性实现速度（Speed through stability） [4:07] Rachel Ibarra: 开发者天生热爱开发，工程师总是渴望工程实现 [9:36] Rachel Ibarra: 为创新去风险化 [9:36] Rachel Ibarra: 立足现实（Anchor in Reality） [9:36] Rachel Ibarra: 购买前先审计（Audit First） [13:28] Rachel Ibarra: 将‘尝试’（Try）武器化 [14:58] Rachel Ibarra: 数据必须是一切事物的基石。如果你打算构建 AI、机器学习，甚至是我们的 BI 和全新系统，倘若没有高质量的数据和良好的数据治理，你能做的事情就非常有限。

Source quotes

[0:04] Rachel Ibarra: the good, the bad and the ugly—very ugly [1:38] Rachel Ibarra: data governance is an adventure that I think we will fight until the end of time [4:07] Rachel Ibarra: developers love to develop. Engineers want to engineer. [9:36] Rachel Ibarra: all hands on deck, stop everything, 24/7 [11:28] Rachel Ibarra: Extraordinary looks different.

Original transcript

[0:04] Hi, thanks so much everyone for being here. Uh so as you introduced I'll be talking about the [0:11] build versus buy framework. Um a little bit about me. Cardinal group um is a mid-market [0:18] company. Before that I ran a data team at another organization and then before that I was an IT [0:23] management consultant. So I have seen the good, the bad and the ugly very ugly at a variety of [0:30] companies and this framework is an amalgamation of that experience. All right, so let's talk about [0:38] the mid-market reality. At the end of the day, we are a property management company. Cardinal [0:45] Group Companies has about um over 200 properties under management right now. We are vertically [0:52] integrated. Our primary value is property management and resident experience. It is not [0:59] technology or software development. At the same time, we want to be innovative. We're not just [1:05] going to say, "Oh, we don't do this, so we'll just kind of buy everything off the shelf and just see [1:09] what happens." by do it. The way that we've taken that on is having years and years of transactional [1:16] data from our property management system as well as a small but very mighty team that I lead that [1:22] will do some custom work. So really at the end of the day the question is how do we innovate? How do [1:30] we do things that are a competitive differentiator while at the same time spending our money wisely? [1:38] Before we jump into the framework, there's let's just anchor in reality. Your current capability [1:44] and where you are right now should dictate your strategy. When I say foundational tech, [1:50] I don't just mean do you have an HR system? Do you have a finance system? Of course, [1:55] those are all really important. I also mean do you have data in systems that is governed? And [2:01] I say governed lightly because let's be honest, data governance is an adventure that I think we [2:07] will fight until the end of time. But what does that foundational technology look like? If you're [2:13] starting at spreadsheets right now, it doesn't mean that you can't get there. But that execution [2:18] path has to look very, very different. And right now, there are a ton of incredible vendors out [2:24] there that are selling the world. You have to be real first about where you are before you can [2:30] say where you want to get and what an effective investment will look like. The next thing that I [2:37] want to talk about is the reality of taking on a new system. I talk about speed through stability. [2:44] And it doesn't mean that you can't move fast, but you do need to question what does stability look [2:50] like at your organization. So I think about like the bullet trains around the world. They [2:54] go really really fast, but they've got a solid infrastructure around them to go fast without [2:58] something catastrophic happening. Remember that when you take when you take on new technologies, [3:06] new agents, um a new data source, you are introducing operational debt. And what I mean [3:13] by that is people have to adjust their processes. People have to adjust how they look at things. [3:18] There's change management. There's resistance. It's inevitable. And it doesn't matter how well [3:23] you do things. It's just part of the journey with technological change. It doesn't mean that [3:28] you've done anything wrong, but it is a reality. The other thing to remember when we talk about [3:34] the importance of foundation and data is that every time you get a new point solution, you're [3:40] introducing a data silo. Now, it of course you will, I hope, integrate it and bring it in, but [3:47] it's something that you have to think about. What does that look like? So when you're expanding, [3:53] when you're making the build versus buy decisions, what does a cohesive ecosystem look like? And it's [4:00] not just the ecosystem of technology, it's the ecosystem of how your organization works. So [4:07] when we talk about the decision matrix, I want to turn the concept of build versus buy on its head a [4:13] little bit and change it to be build, buy, borrow, or try. Build and buy. Those are obvious. We talk [4:20] about those a lot. Borrow where do you have an existing integrated enterprise solution that's [4:26] got a module that you just haven't turned on yet. And then try we talk quite a bit about pilots with [4:34] vendors, but I'm going to encourage you to also try on the build side. And in the next few slides, [4:40] I'll get into each of these a little bit more. So when we think about borrowing and buying, [4:47] I say it's discipline. And when I say it's discipline to do that, it's because let's be [4:52] honest, developers love to develop. Engineers want to engineer. I don't know that I've ever [4:58] gone to a developer and said, "Hey, can you do this?" and they say, "No." They want to [5:03] try something new. That doesn't mean that it's the right thing to do. So, when it comes to borrowing, [5:11] here's what I will encourage you to think about. And it's it's not going to feel good in this day [5:17] and age. But seriously question when is what they have good enough because like I said when you [5:23] introduce new things you will take on operational debt. So when is there something that is a deeply [5:30] integrated enterprise system I'm thinking your HR system marketing CRM uh finance systems and maybe [5:39] they've got another module or it's on their road map for something that you really want or need. [5:45] do you? At the same time, I am certain that there are plenty of vendors out there that [5:50] will have a point solution for you and they're happy to sell that. Sometimes patience pays off, [5:57] especially when you know that you're going to be introducing a lot of change in other areas [6:02] of the business. And then buy. The places where I would encourage buying the most are when it's [6:09] standard business functions. So like I said, HR, finance, CRM, that sort of thing. And then also [6:16] things that are really common to your industry. And I want to be clear that you still do want [6:21] to differentiate in some areas where you buy or build the ecosystem. But for us, I think [6:27] about things like in property management, you've got leasing, you've got maintenance, you've got [6:33] uh taking in leads, you've got tours. It doesn't mean that we won't build any of those things, [6:39] but there's so much out there. We don't need to reinvent the wheel in every single space, [6:44] nor do we frankly have the capital or capacity to. So, building this is the one that is really [6:52] exciting to me and that uh I want people to think very [snorts] seriously about. [6:59] The first area we talk about building is if you truly have a proprietary data advantage. So if it [7:06] means you've got years of data that can be used on a really powerful machine learning model. If you [7:12] have data that you've put together in a warehouse and now all those different data sources can tell [7:18] a story. That's huge. The next one is operational advantage. There are a lot of times we talk about [7:27] these agentic workflows and there are things that are standard but there might be other [7:32] ways where it's how data is moving between systems between teams sort of those internal operational [7:38] efficiencies that you should consider. The next is a niche need. Now where I've seen niche needs the [7:46] most often is when you have legacy systems and you're trying to then bring in new systems. So, [7:53] I think of something like you've got a really old finance system and you need to integrate it with [7:59] something new and shiny. Do you really need to go and buy some extremely expensive middleware that [8:05] you're going to have to kind of adjust anyway? Or maybe just a quick micro service that'll get [8:11] that taken care of and you can move on. And the last, and I see this a lot, is a fractional need. [8:18] So, um, an example that I have that we've done at Cardinal is we have a, [8:25] uh, RAG agent. His name is Stan because he has our standard operating procedures. So, [8:32] it's kind of cute, kind of funny. Um, and he will answer questions for people about, you know, as [8:39] you can imagine with property management, we have tons of standard operating procedures as well as [8:45] um, howto's, policies, employee handbooks, all of those things. And people can ask quick questions. [8:51] I've had three separate vendors come to me on, you know, just offer solutions around AI, [8:58] employee experience, around content management, around all of those things. for like 10 bucks per [9:05] user per month, you know, do the math. Was that And of course, all of those solutions offer a [9:13] ton more than what we've done. But at the end of the day, did we really need all that extra [9:18] stuff to justify like over $100,000 a year? No. So find instances where it's like we need [9:27] this one little thing. It's internal and not that high stakes. we can build this. That makes sense. [9:36] The next is with try and this is where I think about drisking innovation. So where are there [9:48] and and I think we see this more and more now is is the ROI worth it? Is it a good idea to build [9:56] it? Do we really need to buy this? We have taken on sort of stage gates at Cardinal where if we are [10:05] unsure about some of those, we will set up very clear criteria for success for my team and say, [10:12] "Okay, you can build this. Let's go see what that looks like." And start to set KPIs and also [10:20] overhead, get a good sense of the overhead and maintenance reality when it comes to that try. [10:27] And when I talk about maintenance reality, I don't just mean, you know, what does it [10:32] take someone to keep this up, but things like um anything that we build that might interact with [10:40] our residents? Any something going down that's an all hands on deck, stop everything 247 customer, [10:47] you know, 247 my team is there to respond to any issues. So use this concept of trust to [10:58] both get an understanding of the ROI, the value, the feasibility, but also bring the reality of [11:05] what it means to keep that software up and running and what the stakes are when it comes to whatever [11:11] it is you're building. Um, it can be very eye opening, both good and bad. And then of course [11:18] a try when it comes to when it comes to um before you buy anything. So a pilot that sort of thing. [11:28] All right. So your Monday morning playbook. Here's what I will encourage you to think about [11:33] um when you are going back and trying to decide what to build, buy, borrow, [11:39] or try with. The first is just anchor in reality. And like I said, in this day and age, it doesn't [11:47] feel good to anchor in reality because we see what's going on out there and it's like the world [11:52] is your oyster. You can build an entirely AIdriven organization, look at all these incredible things, [11:58] and it doesn't mean that you can't, but extraordinary, especially extraordinary [12:04] for a company that is mid-market or a company that's not technical, that's not, you know, [12:10] where technology is not your primary revenue driver. extraordinary looks different. And so I [12:17] encourage you to really examine and embrace what that reality is. The next is audit first before [12:25] you decide to go and buy something. And this is honestly less fun but very fruitful because [12:33] you'll see a ton of incredible demos. You'll have vendors reaching out to you showing you you know [12:39] aentic HR agentic finance all of this potential and so start by saying what do we need and what is [12:49] maybe already there or on somebody's road map so that we can save that inevitable operational debt [12:56] for something where we really really need it. The third is to build for advantage and question what [13:04] the advantage is. I'm sure that many of you have heard that the advantage of, oh, if we build it, [13:10] we're just we're going to save so much money. Decide if that's true because you're going to pay [13:16] for everything somehow. I guarantee you, you're going to pay for it. Whether it's in people, [13:21] 247 support, change management, customer success, you will pay for it. So instead of it just being [13:28] money, question what that advantage is. The next is to weaponize. Try. And when I say weaponize, [13:37] I mean get ruthless in what ROI means, what fractional need means, what niche means at [13:47] your organization and make it an opportunity to say what do we what are our capabilities here and [13:56] is this really worth investing in? Because another thing that I'll tell you that we've [14:01] learned is that even when we have done some try experiments and they did not make it to [14:06] production and we did go by, our teams learned so much and have used some of that foundational work [14:13] to build other incredible things that did make it to production. And the last is remember that [14:20] you are governing an ecosystem. You're governing an ecosystem of data of interconnected systems [14:28] and also as a leader you're governing what your business ecosystem looks like. So does that mean [14:35] are you introducing that those data silos? Are you introducing operational debt? Do it [14:42] knowingly and make sure that you are still getting that speed through stability. It can be wobbly, [14:51] but make sure you've got the infrastructure around so nothing goes completely off the rails. So [14:57] that's it. Thank you everyone. Uh since you handle data and innovation kind of two different hats, [15:05] what's the similarities and differences in in the two areas covering the two, you know, functions? [15:12] Oh, the two coming together under me. Um, it's the reality that I mean, as we've talked about, [15:20] as I've heard many folks talk about, data has to be the foundation for everything. If you're [15:26] going to build AI, um, machine learning, even some of our BI, our new systems, if we [15:34] don't have good data, good data governance, then there's only so much you can do. So it's really [15:43] it's really about the reality of how all these things are going to operate and operate well.