Discovery on day one, build on days two to five, review on six, live on seven. A walkthrough of every artefact we hand over.
Seven days is not a selling point. It is a constraint that forces decisions that most projects never make.
When a build has six months, scope accumulates. Stakeholders add requests. “While we’re at it” becomes the default answer to every question. By the time something ships, nobody can remember what problem it was supposed to solve, and the person who needed it six months ago has found a different workaround and half-moved on.
Seven days does not allow that. It forces the only question that actually matters: what is the single most important thing this person needs to see to do their job differently? Everything else is a version two.
Here is what actually happens, day by day.
Day 1: Discovery
Discovery is a two-hour session. We do not prepare a presentation for it. We ask questions.
The first question is: walk me through the last time you had to find a number that you did not already know. Not a hypothetical, the actual last time, what happened, how long it took, who you asked. The answer to this question tells us more about what the dashboard needs to do than any amount of requirements documentation.
The second question is: what is the decision that number was feeding? This is where most dashboard projects go wrong. Teams specify metrics when they should be specifying decisions. A metric without a decision attached to it is decoration. We want to know the four to six decisions this person makes regularly where better data would change the outcome.
The third question is: where does that data actually live? Not where it should live, or where you think it lives, where it actually comes from when someone needs it today. The answer is usually three or four systems and at least one spreadsheet. We map all of them.
By the end of day one, we have a one-page brief: the primary user, the four to six decisions we are building for, the data sources, and the definition of done. The brief gets sent to the client for confirmation before day two starts. If we have misunderstood something, we find out now, not on day six.
The brief is the only artefact from day one. We do not produce wireframes on day one. Wireframes encourage feedback on layout when the real question is whether we have understood the problem. Layout feedback at this stage is expensive noise.
Days 2–3: Data model
Days two and three are not visible to the client. They are the foundation everything else sits on.
We connect to the data sources identified on day one and build the data model: what does each source actually contain, how do they relate to each other, where do the definitions conflict? Most systems use the same words to mean slightly different things. “Revenue” in the CRM is bookings. “Revenue” in the accounting system is recognised income. “Revenue” in the ops spreadsheet is invoiced. These are three different numbers. The data model makes the distinction explicit and holds it consistently throughout the build.
We also validate the data in this phase. Every source has quirks: fields that are sometimes blank, records that duplicated during a migration, timestamps in the wrong timezone, a category field that was used consistently until six months ago and then stopped being. We surface these during the model phase, document them, and agree with the client what to do about each one. Some quirks get fixed at the source. Some get handled in the model. Some get noted as known limitations the dashboard will make visible rather than hide.
By the end of day three, we have a tested data model and a confirmed list of the tiles we are building. This is the second sign-off checkpoint: the client sees the tile list and confirms it matches the brief. Changes at this point are normal and cheap. Changes after this point are not.
Days 4–5: Build
Days four and five are when the dashboard gets built. We build against the confirmed tile list and the tested data model. We do not add tiles. We do not redesign layouts mid-build. We build what was agreed.
Each tile has a definition attached to it. Not a tooltip, a full written definition that answers: what is this number, how is it calculated, which source does it come from, what would make it wrong? These definitions are written during the build, not after, because writing them during the build catches calculation errors before they reach the review.
We also write the refresh logic during this phase. How often does each source update? What triggers a refresh? What happens when a source is unavailable, does the tile show stale data with a timestamp, or does it show an error? These are not glamorous questions. They are the questions that determine whether the dashboard is trusted six months after go-live or quietly ignored because “it’s sometimes wrong.”
At the end of day five, the dashboard is built and internally tested. We run it against the last three months of real data and check every tile against a calculation we did independently. If a tile is wrong, we find it now.
Day 6: Review
The review is another two-hour session. The dashboard is live and running on real data. The client and one or two colleagues walk through it with us.
The review has a specific structure. We do not present the dashboard and ask “what do you think?” That question produces aesthetic feedback. We walk through each tile and ask the same question: does this number match your expectation, and if not, do you think the dashboard is wrong or your expectation is wrong?
Both outcomes are useful. If the dashboard is wrong, we fix it. If the expectation is wrong, if the number the client assumed was true turns out not to be, that is usually the most valuable discovery of the whole engagement. We have had clients discover, on day six, that a product line they thought was their most profitable was actually running at a loss once all costs were attributed correctly. The dashboard did not cause the problem. It made the problem visible for the first time.
The output of the review is a short list of confirmed changes and a sign-off on everything that is not changing. Changes from the review are implemented the same afternoon.
Day 7: Live
On day seven, access is handed over. Not a read-only preview, full access to the dashboard, the underlying data model, and the documentation.
The documentation is the third artefact we deliver. It covers four things: what each tile shows and how it is calculated; where the data comes from and how often it refreshes; what to do when something looks wrong (the first three things to check before concluding the dashboard has an error); and how to add a tile or change a calculation if requirements change after handover.
The last section matters more than it sounds. Every dashboard eventually needs to change, a new product line, a reorganisation, a metric the team decides to track differently. If the documentation covers how the model works, the client can make those changes themselves or brief another team to do it. If it does not, they are dependent on us for every small edit forever. We do not want that dependency. Neither does the client.
We also run a thirty-minute walkthrough on day seven: how to navigate the dashboard, how to share a view, how to filter by period or team, and how to export data for the one use case where someone still wants a spreadsheet and that is perfectly fine. The walkthrough is recorded.
What we hand over
At the end of seven days, the client has: a working dashboard on live data; a one-page brief with the decisions it was built for; a tested data model with definitions for every metric; tile documentation with source attribution and calculation logic; a refresh log showing when each source last updated; and a recorded walkthrough of the dashboard with the team.
They do not have a promise to keep iterating indefinitely. They have a finished thing that does what it was designed to do, completely documented, owned by them from day one.
Most clients come back for a second build within three months. Not because the first one was incomplete, because having one dashboard that works makes the gap where a second one should exist impossible to ignore.
If you want to understand what the seven days would look like on your data and your decisions, book a thirty-minute call. Bring the name of the number you most often have to call someone to ask for. That is usually where the first build starts.