The thing that was quick
was never going to hold

Nearly every organisation we work with is on their second attempt. The first one was not incompetent. It was built to answer a question quickly, and it did, and that is precisely why it did not last.

How version one gets built

There is pressure to show something. A person who knows some SQL connects to a couple of source systems, writes queries that produce the numbers people asked about, and puts them behind a dashboard. It takes weeks and everyone is pleased.

The shortcuts that made it fast are all reasonable in isolation. Pull straight from production. Transform inside the report. Skip the raw layer because storage felt wasteful. Grant broad access because the team is small and trusted.

The four things that end it

Someone new needs different numbers, and the logic lives inside dashboards where it cannot be reused, so it gets rewritten slightly differently.

A source system changes and everything breaks at once with no lineage to say what was affected.

The company grows past the point where everyone can see everything, and access has to be retrofitted onto a design that assumed it would not.

Someone asks for a number as it stood last March, and there is no raw history to compute it from.

Why the rebuild is worse than the build

The first version had no users and no expectations. The second has both. It has to be built while the first one keeps running, migrated without a gap in numbers, and delivered to people who now compare everything to what they already have.

It also has to overcome the credibility cost of the first one. The rebuild is frequently the project where the business decides data is expensive and does not work.

What you can do at the start instead

Not much more than version one, honestly. Keep the raw data. Define metrics in one place rather than inside reports. Get lineage from the pipeline rather than from a document. Assume access will need to be restricted later and put it somewhere it can be.

None of those slow down the first dashboard by much. All of them are extremely expensive to add afterwards.

Common questions

Is it wrong to build something quick first? No. Getting a number in front of someone fast is how a data function earns the right to exist. The mistake is letting the quick version become the permanent one by default rather than by decision.

We are already on version one. Is it too late? Not usually. Keeping raw data from today onward, and defining metrics in one place, both work as retrofits. What is genuinely hard to recover is history you never kept.