Structure Is The Shortcut: Scaling Fast Without Breaking Trust

Most reporting projects fail the same way. Not by missing the deadline, but by hitting it. They ship on time, look complete, and then spend the next six months generating support tickets, second-guessed numbers, and dashboards nobody quite trusts enough to act on without checking twice.

We ran into the opposite problem on a project we just delivered, and it's worth explaining why, because the fix wasn't more time. It was a different kind of discipline.

The project itself was a CRM reporting rebuild in Looker for a betting and gaming client, built in six weeks. The data touched customer registrations, reactivations, offers, bonuses, segmentation, geography and performance, the kind of territory where a small modelling error doesn't stay small. It becomes a business decision made on the wrong number.

The instinct under a deadline like that is to move fast by cutting corners. We did the opposite, and it's the reason we ended up delivering far more than we set out to.

The dashboard is only half the job

When people look at a piece of reporting, they judge the visible layer. The KPIs, the tabs, the charts, the filters, the layout. All of that matters. A dashboard should be easy to scan and clear enough that stakeholders aren't decoding it every time they open it.

But the work that actually determines whether a project succeeds is making sure the thing can be trusted. On this project that meant asking, constantly and without exception: what's the grain of this table, is this measure additive, should this filter even apply to this tile, are we using the right row type, does this drill show the right level of detail, is this source field actually available yet, are we fixing a genuine issue or masking one further upstream, will someone else understand this in three months.

None of those questions are glamorous. Nobody puts "checked the row grain" on a motivational poster. But they are the questions that stop a dashboard becoming expensive wallpaper, something that looks authoritative and isn't.

What six weeks actually produced

It's worth being specific about scale, because it surprised us too. The original brief was three dashboards and two analyst explores. What went live was five dashboards, ten tabs and six explore files, including five self-service routes analysts could use without waiting on us. The legacy reporting estate had around 35 visible tiles. The rebuild shipped 123. Filtering went from a handful of basic date, geography and affiliate selectors to 45 filters spanning date granularity, metric and dimension selection, lifecycle, VIP status, LTV segment, classification, affiliate, offer grouping and post-window views.

Some of that growth was planned scope expansion. Some was the team picking up enhancements where the data was ready and the business case was clear. But a meaningful share of it came from something simpler: a well-structured project creates headroom to do more, instead of spending all its time firefighting the basics.

Offers reporting is the clearest example. There was no legacy dashboard for it at all, the client was working from spreadsheets and manual extracts. We delivered two live dashboards covering the full lifecycle from awarded through accepted, consumed and redeemed, plus uplift analysis across selected post-windows. That isn't a rebuild. That's a governed analytical capability that didn't exist before, in any form.

We never made the same mistake twice

One of the biggest improvements was building an audit process around the underlying LookML. Most BI projects lean on manual checking: open the dashboard, click around, hope nothing's broken, maybe eyeball the code, maybe ask a colleague to do the same. That works fine until the project gets bigger than one person can hold in their head.

We built automated checks for the things that are easy to miss and painful later: field references, dashboard filters, listener mappings, missing descriptions, drill behaviour, hidden keys, broken joins, dashboard tabs, navigation buttons, source coverage. The point was never to replace human judgement. It was to remove avoidable mistakes from the human workload, so the judgement that mattered had somewhere to land.

That changed the rhythm of delivery. Instead of trying to remember every standard on every change, we made the change, ran the checks, and got fast feedback. If something failed, we fixed it before it reached a stakeholder. That's the difference between working fast and working blind.

Documentation as delivery, not admin

One of the better calls on this project was treating documentation as part of delivery rather than something to tidy up at the end. We kept a README, a project overview, modelling guidelines, dashboard standards and live changelog notes. That sounds like a lot of overhead, but each piece did a specific job.

The README and project overview explained what existed, which dashboards were live, and what data sources sat behind them. The modelling guidelines set out how the LookML should behave: naming conventions, descriptions, hidden fields, joins, drill rules, date handling, environment routing. The dashboard standards kept the experience consistent across the estate, same navigation logic, same thinking on tabs, filters, status tiles and chart labelling. The changelog gave us a clean, defensible history of what changed and why.

What that documentation actually bought us was memory. Decisions stopped living only in messages, calls or someone's head. That matters far more once a project is moving quickly, because speed is exactly the condition under which context normally gets lost.

Git made the project defensible

Version control was another structural pillar, not a formality. Every meaningful change had a commit. The changelog matched the user-facing work. Branches stayed aligned. We could see what changed, when, and why.

That matters more in BI than people tend to assume. A dashboard stops being "just a report" the moment someone uses it to make a decision. If a metric shifts, a filter moves, or a table gains a new field, you need a trail, and you need to be able to explain it on request, not reconstruct it under pressure. Git gave us that trail, and it made the run-up to delivery calmer: clean diffs, clear commits, no mystery changes surfacing at the worst possible moment.

Separating bugs from enhancements from upstream debt

Being disciplined with the issue tracker did more work than it gets credit for. Some items were genuine bugs, something wrong in the dashboard or the LookML that needed fixing. Some were enhancements: useful, wanted, but not always ready. And some looked like dashboard problems but were actually source data or mart dependencies in disguise.

That distinction mattered because it stopped us forcing logic into the dashboard layer just because a field wasn't ready yet. Sometimes the right answer was that the mart needed the correct attribute at the correct grain first, full stop. That isn't being difficult. That's protecting the numbers. A shortcut that looks like progress but isn't reliable is worse than no feature at all, because it hands people false confidence in something that won't hold up.

Where AI helped, and where it explicitly didn't

We used AI tooling throughout the project, and it's worth being honest about where its value actually sat. AI did not own the delivery. It was a development assistant, a reviewer, a documentation helper, and a way to move faster through repetitive checks and updates.

The judgement still had to come from a person. Understanding the business context, challenging assumptions, deciding whether a change was safe, knowing when not to build something, keeping the tracker, documentation, LookML and stakeholder position all aligned: none of that transfers. AI can help a team move faster, but without structure around it, it's just as capable of creating chaos at impressive speed. The useful part was never "using AI" in the abstract. It was giving it clear project instructions, standards, audit checks and a controlled workflow to operate inside. Less magic wand, more a very capable junior developer who needs good instructions and regular supervision.

Good delivery is a team sport

None of the above would have mattered if the work upstream hadn't been solid. Proper mart designs, source mappings and field definitions gave us something real to build on. When mart definitions are clean, the LookML layer can stay clean too. When they're not, you end up compensating in the presentation layer, patching in business logic that belongs further upstream, and that debt compounds fast.

The difference was visible on this project. The legacy estate had business logic scattered across cubes, with the same lookup logic duplicated many times over and stateful calculations rebuilt independently in multiple places. Because the data engineering work here consolidated all of that into one governed mart layer, with explicit, documented build rules and a consistent approach to nulls, booleans and financial calculations, the reporting layer could stay clean. We were building on something solid instead of working around something fragile.

The data engineering team mattered just as much in practice: they built to spec, turned changes around quickly, and were responsive when issues came up. We were never stuck waiting weeks for a field to be clarified or a mapping to be adjusted.

We had bugs. Every real project does. What mattered was the handling: confirm whether an issue was LookML, dashboard logic or source behaviour; fix what we owned; push source issues back to the right owner with clear evidence; retest once fixes landed; keep the tracker current so nobody was left guessing. By the end, we'd cleared the core bug list and closed off enhancements where the source data was ready and the logic was safe to expose. Not every enhancement belongs in a first release, sometimes the right answer is genuinely "not yet." But where the data was there, the grain was right and the stakeholder value was clear, we took it on. Move quickly. Don't make things up.

What this means beyond one dashboard

The pattern here isn't really about Looker, and it isn't really about one client. It's the same pattern that decides whether an AI or analytics initiative gets stuck in pilot purgatory or actually reaches production: clean, governed data foundations, done properly and early, are what let everything built on top of them move fast without becoming fragile.

Good BI delivery was never really about dashboards. It's about trust: that the numbers are right, that changes are traceable, that filters behave the way they claim to, that known limitations are written down rather than discovered, that source issues aren't hidden inside presentation logic, and that someone else can pick the project up in six months without wanting to start again from scratch.

The six-week deadline mattered, we had to move. But the reason we could move was that the project had structure underneath it. Documentation, audit checks, Git discipline, tracker discipline, clear source ownership and genuine collaboration across data architecture, data engineering and BI didn't slow anything down. They were the reason we could go faster.

That's the lesson worth carrying into the next one. Don't treat a reporting or data initiative as a collection of one-off requests. Treat it as a product, with a system built around it that lets it survive the next change, rather than requiring a full rebuild the next time someone touches it.

‍