Build versus buy for the ADLC control layer
This decision gets made badly in a specific and repeatable way: teams estimate the demo and pay for the maintenance. Here is what the real comparison looks like once you count the parts nobody demos.
Every organisation adopting agentic development arrives at the same fork within about two quarters. The tooling works, the volume is real, and it becomes obvious that something has to sit between the agents and production: criteria, verification, provenance, policy about which runtimes are allowed, evidence for whoever will eventually ask.
At which point a senior engineer says, correctly, that most of this is a few scripts and a database.
They are right about the first version. They are usually wrong about the total, and the gap between those two statements is where a lot of engineering budget goes to die.
I want to be even-handed here, because the industry’s writing on build-versus-buy is mostly written by vendors and reads accordingly. There are good reasons to build this. There are also four costs that consistently go uncounted, and if you count them and still want to build, that is a defensible decision made properly.
The part that really is easy
Give the build case its due, because the first increment genuinely is small.
Reading pull requests from a source control API, matching them to tickets, storing the association, and posting a status somewhere is a week of work for a competent engineer. Adding a check that a ticket has acceptance criteria before work starts is another few days. A basic report of what merged against what is an afternoon.
That system will work. It will be exactly fitted to your workflow, it will use your naming conventions, and it will not require a procurement process. For a single team with one tracker and one source control host, it may be the right answer permanently, and anyone who tells you otherwise is selling something.
The trouble starts when the thing that works for one team becomes the thing the organisation depends on.
The four costs that get missed
Integration surface is the one that changes the arithmetic most. The estimate is always made against the current environment. Then a team acquires a company using a different tracker. Then the platform group moves to a different source control host. Then somebody adopts a new agent. Each of these is a fortnight that was not planned, forever, and the total is not the sum of the parts because the abstraction that made two integrations work rarely survives the fourth.
Correctness under partial failure is where the honest engineers get caught. The happy path is trivial. What is not trivial: a webhook delivered twice, so the same merge is recorded twice and the metrics are wrong in a way nobody notices for a month. A webhook that never arrives, so a change exists in production with no record, which is the exact failure your evidence chain exists to prevent. A tracker rate-limiting you during a busy afternoon so half a day of associations are silently missing. Reconciliation, idempotency and backfill are most of the real work in this category of system, and they are invisible in a demo because demos do not fail.
Evidence quality is the one that gets discovered late and expensively. There is a large difference between “we have a database of what happened” and “we can demonstrate to a third party that this record was not altered.” The first is a table. The second requires signing at the boundary, append-only storage the pipeline cannot rewrite, chained references so deletion is detectable, and key management. Teams build the first, present it during an audit, and are told it is self-attestation. That conversation costs a quarter.
Perpetual maintenance is the cost people acknowledge and then fail to price. The load is not the average, it is the tail: the week the tracker API version is withdrawn, the month a new source control host has to be supported, the incident where the reconciliation job has been silently failing since a dependency upgrade. And there is key-person risk, because this system is invariably built by one enthusiastic engineer, and it becomes unowned the day they change teams.
The comparison that is actually useful
Total cost of ownership is the wrong frame, because it invites a spreadsheet nobody believes. The useful frame is opportunity cost measured in the currency you are short of.
Build makes sense when
The workflow is genuinely unusual, one tracker and one host are likely to stay that way, and you have platform capacity that is not the constraint on product delivery.
Buy makes sense when
The integration surface is broad or growing, an auditor will eventually ask, and your senior engineers are the binding constraint on everything else.
Build fails when
It was estimated as a project and is actually a product. Symptom: it works, nobody owns it, and its numbers are quietly wrong.
Buy fails when
The vendor's model of the life cycle does not match yours, and you spend more effort bending your process than a build would have taken.
That bottom-right quadrant is the failure mode buyers should worry about most and vendors discuss least. A control layer imposes a model of how work flows: what a unit of work is, what states it can be in, what “done” means. If that model is close to yours, adoption is a week. If it is subtly wrong, you get a permanent tax paid in workarounds, and the tax is worse than a build because you cannot fix it.
The diligence question that actually predicts this is not about features. It is: what does this product assume about our process, and is that assumption true? Ask it directly, in those words, and the answer usually arrives within ten minutes of a demo.
The middle path most teams end up on
The framing as a binary is itself part of the problem. In practice the layer decomposes, and the decomposition tends to fall the same way.
The integration and evidence machinery is undifferentiated. Reading four trackers reliably, handling redelivery and gaps, producing tamper-evident records: nobody’s competitive position improves from doing this in-house, and it is the part that is genuinely hard to get right.
The policy is entirely yours. What your criteria standards are, which paths are high-risk, what your definition of done contains, what the escalation path is when a scoped credential is insufficient. This is organisational knowledge and a vendor cannot supply it, which is worth remembering when a product promises to.
The failure is at the seam. Buying a layer that does not let you express your own policy leaves you with the wrong model and no way to correct it. Building the whole thing because the policy must be yours means building the boring reliable parts too, which is where the four uncounted costs live.
Where this breaks down
I have an obvious interest here. This is published by a company selling exactly this layer, and you should weight the argument accordingly. My defence is the paragraph above about building being right for a single team with a stable stack, which is not a claim a sales document would make. Read the four costs and check them against your own experience rather than taking them on my authority.
The costs I listed are not universal. An organisation with one tracker, one source control host, no regulatory exposure and a strong platform team may face none of them meaningfully. That organisation should build, and will be pleased with the result.
Buying does not eliminate maintenance. It converts internal maintenance into integration maintenance, vendor management, and the risk of a roadmap that diverges from your needs. Smaller, usually, but not zero, and anyone presenting it as zero is doing the same thing I am accusing build advocates of doing.
Switching costs are real in both directions. A homegrown system encodes assumptions in ways that make replacement painful. A vendor system holds your historical evidence in their format. Neither decision is as reversible as it looks at the point of making it, and the evidence-portability question is worth asking before signing rather than after.
The takeaway
The build estimate is almost always an estimate of the first increment, and the first increment is genuinely a week. The system is the integration surface, the behaviour under partial failure, the evidence quality, and the permanent maintenance, and none of those are in the estimate.
Decide by asking which resource you are short of. If it is money, build. If it is senior engineering attention, which for most organisations it is, then spending a quarter of it on reconciliation logic for four tracker APIs is a choice with a large and invisible opportunity cost.
If you take one thing into next week: if you already have a homegrown version, go and check whether its numbers are right. Compare its record of last month’s merges against the source control API directly. The discrepancy rate is the most informative number available on this question, and it is usually not zero.
The next piece looks at a cost that appears on no line item and is frequently the largest one in the system: the price of context.