Does AI Change Buy vs Build for Systems of Record?

In 2023, GitHub said developers using Copilot finished tasks up to 55 percent faster in a controlled study. That stat showed up in every board deck I saw for six months. It also triggered a new question from CEOs and CFOs: if software is faster to ship, why are we paying vendors so much?

Here’s my view. AI changes the cost curve for building. It doesn’t change the risk curve for systems of record. CTOs still need a clean line between what you can safely build and what you should keep buying.

Does AI speed change the buy vs build decision for systems of record?

Systems of record are the databases and workflows that define truth for the business. They hold money, identity, entitlements, contracts, and audit trails. They also carry the most regulatory and operational risk.

A practical definition I use with exec teams is this:

A system of record is any system where a wrong write creates legal, financial, or safety exposure.

AI helps you write more code per engineer-hour. It also helps you read and refactor old code. Useful, yes. But it doesn’t remove the hard parts of systems of record.

The hard parts stay hard:

• Data correctness. You still need invariants, constraints, and reconciliation.
• Change control. You still need safe migrations, backfills, and rollbacks.
• Auditability. You still need traceability for who changed what and why.
• Operational load. You still need on-call, incident response, and SLOs.
• Regulatory proof. You still need evidence for auditors, not promises.

Where AI does move the needle is pretty specific.

AI reduces build friction in these areas:

• Integration code. Adapters, ETL jobs, and API clients get cheaper.
• Internal tooling. Admin UIs, scripts, and runbooks ship faster.
• Legacy modernization. You can refactor and add tests faster.

AI does not reduce build friction in these areas:

• Liability. The business still owns the outcome.
• Domain depth. Banking rules and tax rules still bite.
• Long tail maintenance. You still carry the pager for ten years.

So yes, AI changes buy vs build. It pushes more edge capabilities into “build.” It rarely pushes the core ledger into “build” unless you already run a top-tier engineering org.

A decision framework: the SoR AI Build Bar

Most buy vs build templates treat “build” as a single option. That’s the mistake. AI creates a third option that sits between buy and build.

I use a three-lane model.

Lane A: Buy the system of record. You configure it and integrate it.

Lane B: Buy the record, build the experience. You keep the vendor as truth, but you own workflows, UI, and orchestration.

Lane C: Build the system of record. You own the data model, writes, and audit trail.

Now the bar. Lane C needs a much higher bar than Lane B. If you blur that line, you’ll pay for it later, usually at 2 a.m. during an incident.

The SoR AI Build Bar checklist

Use this as a gating checklist. If you miss two items, stay in Lane A or B.

• Regulatory surface. You can name the exact controls you must meet, like SOC 2 CC7, PCI DSS, SOX, or FFIEC. You can map them to system behaviors.
• Data model ownership. You can define canonical entities and invariants. You can also enforce them in code and storage.
• Migration competence. You have shipped at least one zero-downtime migration on a critical datastore in the last 12 months.
• SRE coverage. You run 24 by 7 on-call with error budgets and real SLOs. You can show MTTR and paging load.
• Security engineering. You have threat modeling, secrets management, and a secure SDLC. You can show evidence, not slides.
• Test depth. You can run contract tests, property tests, and replay tests. You can replay production traffic safely.
• Vendor exit plan. You can describe how you would leave a vendor in 180 days, including data export and parallel run.

AI helps with test generation and refactors. It doesn’t replace the discipline behind these items.

A decision matrix you can use with your CFO

Score each row 1 to 5. Multiply by weight. Add totals.

This table forces the real trade. Lane C only wins when differentiation and long-term economics beat liability and ops load.

If you want a tool to run this with your team, use our Build vs Buy Matrix at /tools/build-vs-buy-matrix. It helps you weight criteria and keep the debate grounded.

What org can “build through AI” and stop buying vendors?

Most CTOs I talk to want the upside of building, but they underestimate the org shape required. AI makes it easier to start. It doesn’t make it easier to finish and operate.

The org that can build systems of record

This org has a few clear traits.

• Scale. At least 80 to 150 engineers, with 10 to 20 in platform and SRE.
• Domain experts. Staff engineers who know the domain rules cold. In banking, that means people who have shipped ledger changes under audit.
• Strong product ops. Product managers who can run phased rollouts and parallel runs.
• Architecture governance. A real review process that blocks unsafe writes.
• Incident muscle. A culture that treats outages as a cost center with owners.

AI makes these teams faster. It also makes them more ambitious. That’s good, until you ship faster than you can validate. Speed without verification is just a faster way to break trust.

If you want to measure readiness, pair this with our Architecture Maturity Assessment at /tools/architecture-maturity-assessment. It gives you a baseline for governance and documentation.

The org that should keep buying vendors

This org also has clear traits.

• Small engineering team. Under 40 engineers, with limited on-call depth.
• High compliance load. Audits drive the calendar. Evidence work already strains the team.
• Many business systems. ERP, CRM, and data tools already consume integration time.
• High turnover risk. Key domain knowledge sits with two people.

AI can still help here. It helps you integrate vendors faster and build better internal tooling. But it doesn’t justify owning a ledger.

A good pattern is to buy the record and build the experience. That keeps differentiation where it matters and keeps liability where it belongs.

For vendor choices, use our Vendor Risk Assessment at /tools/vendor-risk-assessment. It keeps procurement from turning into a vibes-based debate.

Examples: core banking, customer experience, marketing, and HR

The best way to think about this is by domain. AI changes build speed in all four examples. The right answer still varies.

Example 1: Core banking platform

Core banking is the classic system of record. It includes the ledger, posting rules, interest, fees, and reconciliation.

If you build it, you own:

• Double entry accounting correctness
• Idempotent posting and replay
• End of day and end of month close
• Regulatory reporting and audit trails

AI will help you generate code and tests. The catch is that the failure modes are brutal. A single bug can create incorrect balances. That turns into customer harm and regulator attention fast.

So what should you do?

• Most fintechs should buy the core. Use a vendor core or a bank partner. Build the product layer on top.
• A bank with 300+ engineers can build parts of the core. Start with a side ledger for a narrow product. Run parallel reconciliation for 6 to 12 months.

Look at how Stripe talks about reliability and correctness. Their engineering blog shows the level of rigor needed for money movement systems, even when you’re not a bank. See Stripe’s engineering blog for examples of the operational bar.

If you do build, treat it like a multi-year program. Use our Command Center at /command-center to track risks, migrations, SLOs, and capacity. Systems of record fail when nobody owns the full queue.

Example 2: Customer experience platform

Customer experience is often not a system of record. It’s a system of engagement. It includes web and mobile apps, personalization, support tooling, and journey orchestration.

This is where AI changes the decision the most.

• You can build a new workflow UI in weeks, not months.
• You can ship more experiments with smaller teams.
• You can integrate more vendor APIs without drowning.

A pattern I like is:

• Buy the record. CRM, ticketing, identity, and billing stay vendor-backed.
• Build the orchestration layer. A thin service that coordinates calls and writes.
• Build the front end. Own the experience and the funnel.

This is also where platform teams can help. Treat the orchestration layer like an internal product. It needs docs, SLAs, and a roadmap, or it turns into a pile of glue no one wants to touch.

If you want to map dependencies before you build, use our Microservices Dependency Mapper at /tools/microservices-dependency-mapper. It helps you see where a “simple workflow” turns into 14 calls.

Example 3: Marketing platform

Marketing stacks are vendor-heavy for a reason. Attribution, ad networks, consent, and deliverability are messy.

AI makes it tempting to build a custom CDP or campaign engine. Most teams regret it.

Here’s the trade.

• Vendors win on integrations. Google Ads, Meta, TikTok, email providers, and data clean rooms change often.
• You win on first party data. Your event model, your segments, your pricing, your experiments.

So the best split is:

• Buy execution. Email delivery, ad connectors, and consent tooling.
• Build data contracts. Event schemas, identity stitching rules, and segment definitions.

If you build the data layer, treat it as a system of record for customer identity. That means audit trails and access controls.

For governance, pair our GDPR Compliance tool at /tools/gdpr-compliance with a real data inventory. AI won’t save you from a bad consent model.

Example 4: HR and payroll

Payroll is a system of record with legal exposure. It also has country-specific rules that change.

AI won’t make you better at tax withholding in Germany or benefits rules in California.

So the default is:

• Buy payroll and HRIS. Workday, ADP, Rippling, Deel, or a regional provider.
• Build internal workflows. Approvals, provisioning, and reporting that match your org.

This is a great place to use AI for glue code. You can build a clean joiner mover leaver flow that ties HRIS to IAM and device management.

If you want to reduce on-call pain, use our Incident Response Planner at /tools/incident-response. HR systems fail at the worst times, like payroll cutoffs.

What CTOs should do next: actions, policy, and architecture

You need a plan that matches your risk profile. You also need a way to stop random build projects from sneaking in.

Immediate actions

1. Inventory systems of record. List every system that can create a wrong write with legal or financial impact. Put an owner next to each.
2. Classify each system into Lane A, B, or C. Do it in a 90-minute workshop with product, finance, and security.
3. Measure delivery speed with and without AI. Use a real metric like lead time for change and change failure rate. Use DORA definitions from Google’s DORA research.
4. Run one pilot in Lane B. Pick a workflow that hurts, like refunds or account changes. Keep the vendor as truth. Build the orchestration and UI.

Policy framework

1. Write a “wrong write” policy. Any service that can write money, identity, or entitlements needs stricter reviews and tests.
2. Set evidence standards. For regulated domains, define what proof you need for audits. Map it to controls. Use SOC 2 Trust Services Criteria as a baseline.
3. Create a vendor exit requirement. Every vendor contract needs data export terms and API rate limits in writing.

Architecture principles

1. Truth stays single. Pick one source of truth per entity. Use events and read models for everything else.
2. Writes stay boring. Keep write paths small, typed, and heavily tested. Put AI-generated code under the same bar.
3. Reconciliation is a feature. Build daily reconciliation jobs and dashboards. Treat drift as an incident.
4. Parallel run is mandatory for Lane C. Run old and new systems together. Reconcile for months, not days.

If you want a stronger RCA loop when things break, use Split Cause at /splitcause. Systems of record fail through chains of small issues, not one big bug.

Bigger picture: AI makes building cheaper, but ownership stays expensive

AI will keep pushing software costs down. That will tempt leaders to treat vendors as optional. The winners won’t be the teams that build the most. They’ll be the teams that build the right thin layers and keep the risky core stable.

I also see a second-order effect. Vendor products will ship AI-assisted configuration and customization. That will narrow the gap between buy and build for many domains. CTOs will need sharper vendor governance, not less.

So here’s the question to bring to your next staff meeting: if a vendor disappeared in 180 days, which systems would you be proud to own, and which would put you out of business?

Sources

1. GitHub Copilot research: productivity and developer experience
2. Google Cloud: DORA and DevOps research
3. AICPA SOC 2 Trust Services Criteria resources
4. Stripe Engineering blog
5. Martin Fowler on Strangler Fig pattern

Sources:

• https://github.blog/2023-05-25-github-copilot-research-recognizing-the-impact-of-ai-on-developer-productivity-and-happiness/
• https://cloud.google.com/devops
• https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
• https://stripe.com/blog/engineering
• https://martinfowler.com/bliki/StranglerFigApplication.html