--- title: "Why CAT?" description: "Build it yourself, or buy a platform. CAT is the third option." url: "https://docs.justcat.it/what-is-cat/why-cat/" --- # Why CAT? A data team that decides to start testing its data is offered two options: build something itself, or buy a data quality platform. Both are reasonable. Both tend to disappoint, for opposite reasons. Most data teams choose one, live with it for a couple of years, and quietly conclude that testing data is simply hard. It is not. There was just never a third option. **CAT is the third option.** One question separates the three, and it is not a feature comparison: **what does this change for the data team, in its delivery process, tomorrow morning?** Not in six months, not once the programme lands — tomorrow, on the next release. Judged that way, the two familiar options do remarkably little. ![A timeline comparing when the first data check runs under each of the three options — weeks, months, or day one.](first-check-timeline.png) *The gap before the first check is the part nobody plans for.* ## Option one — build it yourself Somebody on the data team writes the checks. It starts well, and it starts cheap. - **What it looks like:** scripts, stored procedures, a framework built in one person's own style — often in a language or a pattern nobody else on the data team uses. Increasingly, something vibecoded in an afternoon. - **On vibecoding:** no objection, and no irony intended. Vibecoding is coding, and the result is real code that really works. It is also real code somebody now owns. Having an AI write it changes who typed it, not who maintains it. - **What it changes day to day:** a great deal at first — those first checks are genuinely useful. Then it inverts. Maintaining the framework starts costing more hours than the framework saves, and in the long run it is more pain than gain. - **Why it stalls:** it is heavy to develop and heavier to maintain, it is bound to the technology it was written against, it sits outside the team's normal delivery process, and it tends to test what is easy to test rather than what the business cares about. - **What it costs:** no licence, and yet genuinely expensive — paid in the time of your most senior people, every year, for as long as it survives. The most expensive kind of cost, because it never appears on an invoice. - **What finally kills it:** the person who wrote it moves on. What remains is code nobody wants to touch, so it quietly stops being run. ## Option two — buy a data quality platform Choose a platform, run the procurement, roll it out. - **What it looks like:** a vendor selection, an implementation project, an owner, and a plan. - **What it changes day to day:** for the data team itself, usually nothing. The platform is bought for the organisation — oversight, reporting, a governance commitment — while the daily struggle with data quality carries on exactly as before, now with a tool the team is also expected to feed. - **Why it stalls:** the decision and the rollout are measured in months. It needs specialist skills the data team does not have, and it assumes a level of data maturity most teams have not reached. - **What it costs:** expensive to licence and more expensive to put in — implementation, integration, and the people to run it, all spent before anything comes back. Then a dependency on one vendor and one stack, which becomes its own cost the moment your stack changes. - **What finally kills it:** by the time it is live, people have worked around the original problem. The platform exists. Nobody uses it. You are still paying for it. Powerful — if you were already mature enough to need it. ## Option three — CAT Neither of the above, deliberately. A testing toolkit: not a homegrown framework, not a platform. - **What it changes day to day:** the next release. A check written this morning runs before this afternoon's deployment, and the data team knows something it did not know yesterday. That is the whole proposition, and it is measured in hours rather than quarters. - **In production the same day.** Installation takes a minute, a first meaningful test takes minutes more, and there is no rollout to survive first. - **No new specialist skills.** Checks are readable by anyone on the data team, and can be drafted by CAT Pilot or written by an agent. - **One process, end to end.** Writing a check, running it, wiring it into your pipeline, and keeping the results over time — not a set of tools stitched together. - **Technology agnostic.** The same test definitions work across databases, files and BI models, so changing part of your stack does not invalidate your tests — and no vendor owns your testing practice. - **Business buy-in, not just engineering approval.** Checks read as statements the business recognises — "revenue in the report matches revenue in the source" — so data quality stops being an internal engineering topic. ## The three options, side by side Two options. And the third. | | Option one — build it | Option two — buy a platform | Option three — CAT | |---|---|---|---| | **Time to first real result** | days to write, then it grows | months, through selection and rollout | the same day | | **Changes for the data team tomorrow** | some, then steadily less | usually none | the next release | | **Skills needed** | whoever wrote it | specialist talent, usually hired | anyone on the data team | | **Maturity assumed** | none, but no guidance either | considerable | none — opinionated on purpose, so there is somewhere to start | | **Tied to** | one person, one technology | one vendor, one stack | nothing — the tests are plain text you own | | **Across your stack** | written against the technology it was born on | what the platform supports | technology agnostic — the same definitions across databases, files and BI models | | **Business visibility** | rarely any | reporting, once configured | built in, from the first check | | **What it costs** | no licence, but a permanent claim on your most expensive people | licence, plus an implementation programme before any return | starts free — prove the value before anyone signs anything | | **In two years** | unmaintained, no longer run, still paid for in workarounds | live, worked around, still invoiced | still running, and larger | > **🐱:** If you already built something yourself, you are not starting over. The checks you wrote by hand encode real knowledge about your data — what matters, what breaks, what people argue about. Moving them into CAT keeps the knowledge and drops the maintenance. ## What this actually changes The reason to take the third option is not that the first two are bad ideas. It is that both turn testing into an event — a thing to build, or a programme to roll out — and testing only works when it is ordinary. CAT is made to be picked up and used, this week, by the data team that already has the problem. So judge all three by the only question that matters to the people doing the work: *what is different about our next release?* Option one answers "less every year". Option two answers "nothing". Option three answers today.