Build vs Buy

The 30-second answer

Yes, you could build this yourself. Same reason you could build your own database, identity provider, or observability stack. The question is whether the engineers you would put on it are the engineers you would rather have shipping your actual product, and whether you would rather spend the next two years discovering the bugs we have already fixed.

Most teams who ask this question are evaluating tradeoffs honestly. Below are the seven things that surprise teams who go down the build path, in rough order of how often they cause regret.

1. The compliance engine is a moving target

Frameworks update. NIST 800-53 had a major Rev 5 revision. AICPA SOC 2 published supplemental 2022 guidance. CMMC Phase 2 enforcement starts November 2026. FedRAMP 20x mandates OSCAL submissions September 2026. Each update means going back through every per-control evaluator and adjusting the logic and the citations.

MergeWhy maintains 15 framework engines with hundreds of controls each. That is a full-time team. Most internal builds start with SOC 2, get to “we covered the controls” in six months, then add HIPAA and discover the maintenance load. Framework #3 is where most internal builds quietly stall.

2. The cryptography has subtle bugs that only show up in production

We learned this the hard way. Specific examples from our own commit log:

• Audit-chain hash determinism. Postgres jsonb does not preserve key insertion order, and timestamp columns round-trip with microsecond drift. Naive hashing produces different output every time you recompute. Fix took three iterations: recursive deep-key-sort, ISO-8601 timestamp normalization, and an insert-then-rehash pattern to avoid Date round-trip drift entirely.
• Sigstore Rekor signature format.Rekor's hashedrekord type requires Ed25519ph (pre-hashed), not pure Ed25519. Burned half a day discovering this. Most reference implementations get it wrong on the first try.
• Linear OAuth issue lookup. The issue(id: $id) query returns null for actor-bot tokens issued via the Linear-GitHub integration. Undocumented. Solution: use issues(filter: { number, team.key }) instead, which works for every token type Linear accepts.
• Linear credential storage key. Personal API tokens get stored under apiKey; OAuth tokens under accessToken. A code path that reads only one will silently return empty results.

A team building this from scratch will hit every one of these. They will not know why their auditor rejects the evidence until they debug all four.

3. The auditor relationship is harder than the code

Audit standards: AICPA AS 1105 (Audit Evidence), AS 2201 (ITGC), AS 2315 (Stratified Sampling). PCAOB has separate guidance. Each Big 4 firm has its own evidence-format preferences. AuditBoard wants three specific CSVs with UTF-8 BOM. Workiva wants a different shape. Your auditor wants samples in their preferred form.

The product knowledge that goes into “your auditor will actually accept this” is months of conversations with audit firms. Internal compliance teams do not usually have that bandwidth or those relationships. Building the code is 30 percent of the problem; making the output land with auditors is the other 70.

4. OSCAL 1.1.2 is a thousand-page spec

OSCAL is the NIST standard for machine-readable compliance documents. SSP plus Assessment Results plus POA&M each have nested types running into hundreds of pages of schema. Reference implementations are sparse. Validators disagree.

In 2025, zero FedRAMP OSCAL submissions were accepted on the first attempt out of those filed. The deadline becomes mandatory September 2026. If FedRAMP is on your roadmap, OSCAL is a six-month engineering investment with a high probability of still being rejected on first submission unless you have prior experience with the spec.

5. Anchoring to a public log is a non-obvious architectural choice

Most internal builds make a private append-only log and call it tamper-evident. That does not satisfy the auditor's actual question, which is: “How do I verify your evidence without trusting your database?”

The answer is anchoring the chain head to a public transparency log. We use Sigstore Rekor — the same log Linux distros and the Cloud Native Computing Foundation rely on. Rekor entries are immutable, publicly inspectable, and verifiable with the Rekor CLI from any machine on the internet. This is the architectural choice that most internal teams skip past, and it is what auditors actually want when they ask for “independent verification.”

6. Maintenance is forever

Once you build it, you own it forever:

• GitHub changes their webhook API → your handler breaks.
• Linear changes their GraphQL schema → ticket enrichment breaks.
• NIST publishes 800-53 revisions → FedRAMP and CMMC engines update.
• AuditBoard changes their CSV import format → your export breaks.
• PCAOB updates AS 2315 sampling guidance → your sampling engine changes.
• Your auditor switches firms → re-test the entire output package.

That is roughly half to one full-time engineer in perpetuity. The build cost is a fraction of the maintenance cost.

7. Opportunity cost

A typical three-person engineering team for 18 months at fully-loaded $300K each comes to $1.35M to build this. The SaaS alternative is $999/mo for Growth or $50K to $200K/yr for Enterprise. Even assuming a 100 percent successful build (generous), that is a two to three year payback for a function that is not your core product.

The team that would build this is the team that would otherwise be shipping the product your customers actually pay for.

When DIY actually makes sense

We are honest about this. Build it yourself if any of the following apply:

• You only need one framework, you only have a small number of repositories, and you do not anticipate adding more frameworks later. SOC 2-only, three repos, no CMMC ambitions = a small internal tool is fine.
• You have a team member who has shipped audit-grade evidence systems before and you have the audit-firm relationships to validate output against real audits.
• Your industry has unusual evidence requirements that no off-the-shelf product covers (highly classified environments, custom federal requirements, niche regulatory regimes).
• You are explicitly OK with maintenance burden because compliance IS your core product.

For everyone else, the math points the other direction.

How we'd answer your specific concern

If you are evaluating this seriously, the seven concerns above are not equally weighted for every team. Most prospects worry most about one of three things:

• Maintenance load (#1, #6)— “will we have to keep building this forever?”
• Auditor acceptance (#3, #5)— “will the output actually pass our auditor on the first attempt?”
• Opportunity cost (#7)— “is this the best use of our engineers?”

Tell us which one you are most worried about and we will give you the honest answer for your situation rather than a sales pitch. Email dheeraj@mergewhy.com or book 15 min at mergewhy.com/contact.