Buy vs. build: when SaaS still wins, and when to build your own agent

For fifteen years the default answer to “buy or build” was “buy” — SaaS was cheaper to start, someone else carried the maintenance burden, and building meant hiring a team you didn’t have. Cheap inference, mature agent frameworks (LangGraph, CrewAI, AG2), and coding agents that can scaffold a working prototype in an afternoon have made “build it ourselves” a genuinely live option again, in specific cases — not universally.

Where build now wins

Thin, well-defined workflows around your own data. If the “product” is really a few LLM calls stitched to your own database — a support-ticket triager, an internal research assistant — a small team can now build and maintain that faster than they can evaluate, buy, and integrate a SaaS tool, especially with modern agent frameworks handling the orchestration boilerplate.

When the SaaS tool’s core value is a thin wrapper you could replicate. Teams on Hacker News regularly describe standing up their own agent observability or workflow tooling after concluding a vendor’s dashboard didn’t justify its price relative to what their own stack already logged — see the Ask HN thread on productionizing agentic applications, where multiple builders describe exactly this tradeoff going both ways depending on how custom their pipeline was.

Where buy still wins, clearly

Anything with real compliance/security surface area. SOC 2, audit logging, SSO, data residency — this is expensive and slow to build correctly, and a vendor who’s already done it for hundreds of customers has amortized that cost in a way a single team never will.

Anything where the hard part is breadth of integrations, not the core logic. A CRM or support-ticket system’s value is largely the hundred integrations and edge cases it already handles — rebuilding that surface area yourself rarely pencils out even when the core “agent loop” is simple.

When you don’t want to own the maintenance. The Launch HN thread for Lucidic, an agent observability startup, makes the case directly: “traditional LLM observability platforms don’t capture the complexity of agents” — teams that tried to bolt agent-tracing onto generic logging found themselves maintaining a bespoke observability layer nobody signed up to own long-term.

A practical framework

Ask three questions before defaulting either way:

1. Is the hard part your business logic, or the surrounding plumbing (auth, compliance, integrations, uptime)? Build if it’s the former, buy if it’s the latter.
2. Will this need to change when the underlying model changes? If yes, who owns that maintenance forever — and is that actually cheaper than a subscription?
3. Could Crail’s agent-readiness data change the calculus? A tool that’s expensive to integrate manually but publishes a real MCP server may be far cheaper to adopt than its price tag suggests, since an agent can wire it up without custom integration work — check the vendor’s agent-readiness score before assuming “build” is cheaper.