The prototype is a weekend, the product is not

Luhn and a BIN check will validate card numbers reliably in an afternoon. National identifiers, IBANs and key formats are pattern work with known shapes. A competent engineer gets a credible demo quickly, which is exactly why this looks buildable.

The demo is also where most internal builds stop being representative, because real traffic is mostly prose and the prose is where the difficulty lives.

A sixteen-digit number beside the word example is not a card number. A column headed Name holding four hundred entries is a record rather than a mention. Getting those judgements right is the difference between a tool people keep and one they learn to dismiss.

Then there is everything that is not the browser: desktop applications that pin their certificates, file attachments, pasted screenshots, and agents acting on a person's behalf. Each is its own capture problem.

And enforcement has to act inside the time a send already has. A control that freezes the browser gets uninstalled by the person it protects, which is why a deadline and a fail-open path are design requirements rather than nice to have.

Capture bound to a page's structure stops working when that page changes, and it stops silently: the console simply reports nothing, which is indistinguishable from a quiet week.

Catching that needs tiered selectors, health telemetry per connector, and something that proves capture still fires. It is ongoing work with no visible output when it is going well, which makes it the first thing to lose a maintainer, and the resulting gap is the silent kind.

Build estimates are usually honest about the first version and silent about the maintenance, which is where this particular category is unusually expensive. The detectors are the smallest part of it.

Three things change underneath you. Providers ship interface changes that break a composer hook without warning. New tools appear, and an assistant added inside software you already approved is not a new hostname at all, so a surface list needs revisiting rather than extending. And false positives need tuning against your own documents, continuously, because the cost of a noisy rule is that people learn to dismiss the warning.

None of that is a reason not to build. It is a reason to price the second year rather than the first, and to be clear about who owns it when the engineer who wrote it moves teams.

Build decisions are made by the engineer who is excited about the problem, and maintained by whoever inherits it. That gap is a bigger factor in how these projects end than any technical consideration.

A detection system is not a project that completes. It needs somebody watching whether capture still works after a provider ships a redesign, tuning rules as the corpus changes, and answering for it in an audit. That is a part-time ongoing commitment rather than a quarter of work, and it is rarely anybody's stated objective once the person who wanted it has moved to another team.

The question worth asking before starting is not whether you can build it. It is who will own it in eighteen months, what else that person will be responsible for, and what happens when the two conflict. If there is no clear answer, the realistic outcome is a system that runs, reports healthy, and quietly stopped catching things some months ago.

There is a version of this decision where building wins clearly, and it is worth naming rather than pretending otherwise.

If the sensitive data is specific to your business, an internal identifier format, a product codename, a customer reference scheme, then nobody else's detector knows about it and you will be writing the rules regardless. If you already run endpoint software with a team that owns it, the deployment cost that usually dominates is already paid. And if the requirement is genuinely narrow, one surface, one data class, one team, then the maintenance burden stays small enough to carry.

The hybrid is the common ending: buy the engine and the surface coverage, write your own rules on top of it, because custom rules are the part that needs your knowledge and surface coverage is the part that needs somebody to maintain it every quarter. Any product worth buying lets you do that without professional services.