Buy AI tools when the problem is common and a vendor can carry security, compliance and upkeep for you, and build only when the workflow is specific to how your firm works, the lighter options have been tried, and someone will own the result after launch.
AI has made software faster to build. It hasn’t made software cheaper to own. Many good build-vs-buy decisions come down to that distinction.
Who this is for
CFOs, COOs and technology leads weighing a growing stack of AI subscriptions against the option of building their own tools or agents.
The short version
- Treat build vs buy as a ladder, not a binary. Start at the lowest rung that solves the problem.
- Buy for common problems. Build for differentiating or awkwardly specific ones.
- Before building, name the owner, the maintenance plan and the data controls.
The build-vs-buy ladder
Work up these rungs in order. Stop at the first one that genuinely solves the problem.
Rung 1: Use what you already have, better. Many firms already pay for general AI assistants and AI features inside their existing software. Better training and shared prompts can unlock more than another purchase would.
Rung 2: Configure. Most general assistants let you set up reusable instructions, shared projects or custom assistants with your reference documents. This is quick, cheap and reversible.
Rung 3: Buy a specialist tool. For a well-defined, common job, a vendor product built for your industry or function may do it better than anything you’d configure or build, and the vendor handles updates.
Rung 4: Connect. If the work requires moving information between systems you already use, a connector or small integration may be enough. This is often where the real time savings sit.
Rung 5: Build. A custom agent or internal tool designed around your specific workflow, data and controls.
When buying is usually the better choice
- The problem is common. Many firms have it, so vendors compete to solve it well.
- Compliance and security are heavy. A mature vendor’s certifications, audits and controls are hard to replicate.
- You have no one to own it. Unowned software becomes a risk over time, however quickly it was built.
- The workflow isn’t part of your edge. If doing it differently wouldn’t make you better at your core work, standard is fine.
When building is usually the better choice
- The workflow reflects how you make money. Your way of screening, pricing, reporting or advising is a source of advantage, and generic tools flatten it.
- People stitch tools together by hand. Repeated copy-and-paste between systems is a strong signal.
- You pay for a broad platform and use a narrow slice. A focused tool may be simpler.
- The data can’t leave your environment. Requirements may rule out some vendor options.
Questions to answer before you build
- Who owns this in twelve months? By name, with time in their role for it.
- How is access controlled? Who can use it, what can it see, and what actions can it take?
- How will you know if it quietly breaks? Models, APIs and data change. Something has to notice.
- What happens if the builder leaves? Documentation, code access and handover matter.
- What does it cost to run? Hosting, model usage, monitoring and maintenance, not just the build.
- Could a lower rung get most of the value? If so, try that first.
If several of these have no clear answer, you probably aren’t ready to build yet.
A simple scoring approach
For each candidate workflow, score from 1 to 3:
- Specificity: how unique is this to your firm?
- Frequency: how often does it run?
- Integration need: how many systems does it touch?
- Sensitivity: how restricted is the data?
- Ownership readiness: is there a capable owner?
High specificity, frequency and integration need, combined with real ownership readiness, point toward building. Low specificity points toward buying or configuring, whatever the other scores.
Common mistakes
- Building to save license fees. Maintenance can outweigh the savings.
- Buying to avoid hard thinking. A new tool won’t fix an unclear workflow.
- Skipping rungs 1 and 2. Many firms underuse what they already pay for.
- Letting one enthusiast build critical tools unreviewed. Speed is not the same as reliability.
- Ignoring the exit. For bought tools, know how to get your data out. For built ones, know how to keep them running.
When you do not need us
If your need sits clearly on rungs 1 to 3, you can usually decide this yourself with the questions above and a couple of vendor trials. You may also not need us if you have an in-house engineering team that already maintains internal tools and can apply the same discipline to AI.
How Ruby helps
- AI strategy: a clear build-vs-buy recommendation across your workflows, including when to keep what you have.
- AI engineering: secure, maintainable agents, connectors and internal tools when building is the right answer.
- AI training: so your team gets full value from the tools you already pay for.
A practical first step is one hour of AI training, which often shows how much rung 1 can deliver.