“Data first” means you settle what your core records are, how each one is identified, where the original version lives and how every figure traces back to it, before you build the dashboards, apps and AI that use them. It is an order of work. The data model is decided early and on purpose, rather than discovered later from whatever the first screen happened to need.
The reason is simple. You can only build a skyscraper as high as the foundations allow. Screens are cheap to change. Data that was modelled wrong is expensive to change, because everything above it has learned the wrong shape.
What does it look like in practice?
I learned it by building a market-data platform twice. The first time, I built the exciting part first: models, analysis, a large web app. Its last layer, the one closest to the models, reconciled every one of its partitions against what was on disk. Its first layer, the one everything else read from, had no such discipline and filled up with duplicates and contradictions. The second version inverted the order and modelled nothing until the foundation could be trusted. These are the decisions that made the difference:
- Keep the raw data exactly as it arrived. Byte for byte, with a fingerprint, never overwritten. Every cleaned table can then be rebuilt from it, so a mistake in cleaning costs a rerun rather than the data.
- Give every record a key that survives change. My first design keyed on stock tickers, and tickers are reused when companies merge, rename or fold. A reused key quietly welds two unrelated companies into one row, and nothing raises an error. The fix was an internal id, with the ticker and the dates it was valid for held beside it.
- Record when you knew something, as well as when it happened. Figures get revised. Store only the latest and you can never reconstruct what you believed on a given day, so every look backwards is quietly wrong.
- Version the configuration and stamp it on every run. Then “which settings produced this number?” has an answer.
- Make absence visible. A record that failed to match should show up as a stated gap, never as an empty result that looks as if nothing happened.
None of that is specific to markets. Swap tickers for customer numbers, product codes or account ids and every point still applies.
Why does it matter more as you grow?
Because every new system copies your data’s mistakes. When the company is small, one spreadsheet is the truth and everyone knows where it is wrong. A few years on, three tools hold three versions of the customer list, and “how many customers do we have?” has a different answer depending on who you ask. Each new tool, report or AI assistant inherits whatever shape the data has when it arrives. Fix it before the second tool and it is a tidy-up. Fix it after the tenth and it is a migration.
Does data first mean a big data project before anything useful?
No, and that is the most common misreading. It means the first useful thing you build stands on the right foundation, however small it is. You don’t need to model the whole business. You need the handful of records the first feature touches to be modelled properly, with the raw source kept, the keys honest and the numbers traceable. The next feature then extends a foundation instead of laying its own.
It also means turning down some shortcuts. The pull to paste a figure into a slide, or to type a number into a page because it is quicker, never goes away. On the home page of this site, the counts of commits and tests behind my work are read from the repositories when the site is built, and never typed, so they can’t drift from the truth.
Anyone can build an app in an afternoon now. What can’t be copied is what a business knows, and that lives in its data.
What does AI change?
It makes all of this more urgent. A model answers fluently from whatever you give it, right or wrong. A report built on duplicated customers is wrong in a way someone might spot. An assistant built on the same data is wrong in a confident, well-written paragraph, and people believe paragraphs. Data first is how you make sure the thing your AI reads is worth reading.
The traps are rarely dramatic. One data vendor I use ignores any query parameter it doesn’t recognise and returns everything, with a success code. A filter that doesn’t exist looks exactly like a filter that matched every record. On the second platform, a parameter can only be marked as relied on once there is recorded proof that it changes the result. That rule lives in the database, so the trap is impossible rather than merely documented.
How can you tell if your foundations are sound?
Ask these of any number your business relies on:
- Where did it come from, and can I see the original?
- If the source sends a correction, what changes, and do we keep the old value?
- Could two records here really be one thing, or one record really be two?
- If last night’s job failed, where would that show?
If the answers are “someone knows” or “it would just be blank”, the foundation needs work before anything else is built on it. Tracing one disputed figure back to its source line usually tells you more about your data than a month of dashboards.
The short version
Data first is an order of work: core records, honest keys, the raw copy kept, every number traceable, and only then the screens and the AI. It costs a little at the start and pays back every time you build something new. I focus on the foundations, so you can focus on what you are building on them.