Every CTO we work with is holding a build-vs-buy decision. The failure mode is not that people pick wrong — it's that they don't apply a framework, and end up rationalising whichever choice matches the team's mood that week.
Here is the framework we bring into every engagement. It's not novel. It's just the version that survives contact with real projects.
Rule 1: Buy your commodities, build your differentiators
Your billing? Buy Stripe. Your email? Buy Resend or SendGrid. Your auth? Buy Clerk, Auth0 or Emergent Auth. Your CRM? Buy Salesforce or HubSpot.
Your product experience — the thing the customer actually pays you for? Build. Every serious differentiator you have will erode if you outsource it to a generic SaaS that also serves your competitors.
Rule 2: If the market moves faster than the vendor, build
This is the rule that killed a lot of no-code + low-code decisions in the AI era. Between 2023 and 2026, LLM providers released major capabilities every six weeks. Any SaaS that bought vs. built its AI features 18 months ago is now behind — the vendors couldn't keep up.
Rule of thumb: if the technology underlying the feature is doubling in capability every 12 months, build. If it's stable (payments, auth, log ingestion), buy.
Rule 3: If integration cost exceeds build cost, build
The hidden cost of buying is integration. Vendor APIs change, SSO configurations drift, webhook payloads break, and vendors get acquired. If integrating and maintaining a vendor SaaS costs more over 3 years than building the equivalent from scratch, the buy was the wrong call.
We've seen this exact miscalculation on document parsing (buying an off-the-shelf OCR SaaS that couldn't handle the client's document shapes), on search (buying Algolia at $10k/mo when a Postgres FTS index would have covered 95% of the use case), and on notification systems (buying a $2k/mo transactional email vendor when Resend at $20/mo covered everything).
Rule 4: If compliance ties the buy to your walls, build
This is why healthcare, legal, banking and defence still build so much. Any vendor SaaS that requires data to leave your compliance perimeter is fighting an uphill regulatory battle. Custom-built, sovereign, single-tenant deployments (like our Document Intelligence platform) exist because 'trust the SaaS with your regulated data' is a career-limiting bet.
The four cases where building is almost always right
1. **The core product experience** — build. 2. **AI features that will differentiate your product for the next 24 months** — build. 3. **Anything that touches regulated data behind a compliance perimeter** — build. 4. **Anything where the vendor's roadmap is meaningfully slower than your product velocity** — build.
The three cases where buying is almost always right
1. **Undifferentiated infrastructure** (auth, payments, email, logs, observability, error tracking). 2. **Categories with 10+ mature vendors and stable APIs** (analytics, CRM, HRIS). 3. **Anything a $30/mo SaaS covers before you have paying customers**.
How Origami approaches this
We don't have a build-bias. About 40% of our discovery engagements end with 'don't build — buy X, integrate Y, and here's how'. Because the goal is your outcome, not our billing hours. When we do recommend building — and we do, often — it's because we've walked through this framework and one of the four 'build' triggers fired.