Mission Control · internal · architecture
The Baker's Dozen runs on spreadsheets, Power BI, and GobbleCube, with no engineer to own a stack. So the question isn't which warehouse is best. It's what they can operate themselves once we leave the room. This is how we think about that.
The single distinction that decides every other choice on this page.
A no-IT org can do the operating jobs. They can click a weekly export, drop files in a folder, watch a number move, and flag when it looks wrong. They cannot do the building jobs. They can't keep a script alive, fix a connector that broke overnight, or model a schema.
So every step we hand them has to be something a vendor keeps running, or something so simple it can't really break. The moment a step needs an engineer to stay alive, it belongs to us or to a retainer, never to them.
Buy the plumbing, never build it in-house. If keeping a step running needs code, it's the wrong step for The Baker's Dozen to own.
Before scoping anything, we need to know how data leaves GobbleCube. If it gives structured exports (a CSV download, an API key, a scheduled email), we have a real pipeline. If it only shows dashboards on screen or spits out PDF reports, that source is capped at "read and summarize" and never joins the rest cleanly.
I can't verify GobbleCube's export capability. It's the first question for their data owner, and the answer changes the whole shape of Part Two. Same question applies, less urgently, to Power BI (we want the underlying datasets, not just published dashboards) and the production and supply-chain files.
Get one real export sample from each source before Session 1. GobbleCube is the pivotal unknown. Everything downstream assumes the numbers can leave their tools as data.
Shalin's proposal was a daily job that dumps everything into one Google Drive folder. The instinct is good. One part of it quietly defeats the goal.
Keep this. One place, daily cadence, manual kickoff is fine, no IT needed. That's the correct shape for them, and the snapshots give point-in-time history that Power BI mostly forgets.
Change this: don't dump PDFs. A PDF is a picture of the numbers. The instant you want to ask questions of the data, PDF fights you. An AI reading tables and charts out of a PDF guesses, and it can't aggregate across many of them, which is exactly what leadership will ask for. Export the structured file the source already offers (CSV or a Google Sheet) and the same daily habit now has a real query path.
| Daily PDF dump | Daily CSV / Sheets dump | |
|---|---|---|
| What it is | A picture of the numbers | The numbers themselves |
| AI can query it | Reads and summarizes a few, guesses at tables and charts | Aggregates, joins, and computes reliably |
| Trend over time | Open every snapshot, slow and lossy | One growing table, one question |
| Effort to produce | Same weekly click | Same weekly click |
| Use it when | Only when a source refuses to export data | Every source that will export data |
Keep the instinct, change the format. One Drive folder, one cumulative Sheet per source, structured not PDF. PDFs go in a pdf-only corner reserved for sources that leave us no choice.
Same destination the whole way. Each phase is only reached when the previous one starts to hurt, so nothing is over-built ahead of need.
Now · zero engineer · near-zero cost
Daily CSV or Sheet exports into one Google Drive folder, one cumulative Sheet per source. Query it with Gemini in Workspace, NotebookLM, or Claude. This alone proves whether "just ask the business" earns its keep, before anyone spends money.
When a manual dump gets tedious
Replace only the painful source with a bought connector (Hevo or Daton, both Indian and D2C-focused with vendor support) feeding BigQuery. The vendor maintains the pipe. Still no code kept alive in-house. Do this per-source, only as each one earns it.
When questions outgrow the files
Define metrics once so plain-language answers come back accurate instead of plausible. The warehouse and this semantic layer are the actual build. The chat on top is the quick part (the dbt benchmark: ~33% raw text-to-SQL versus 98–100% when grounded in a semantic layer). A fractional analytics engineer builds it, The Baker's Dozen operates it.
One named, non-technical data owner inside The Baker's Dozen who runs the daily habit and owns the questions, plus a fractional analytics engineer on retainer for the walk and run steps. They operate. The retainer builds and repairs. Nobody at the bakery has to become an engineer.
Options, roughly in order of when they fit:
Point it at the Drive folder. Strong at "what does this say," weaker at math. Good for the crawl phase.
Native where the data already lands. Fits if exports go into Google Sheets, which is the plan.
The best chat surface once a clean semantic model exists. Belongs to the run phase, not before. Assumes it's on their plan.
Ad-hoc questions over a CSV any time. No setup. Good for one-off exploration.
AI doing arithmetic over many rows is still imperfect. For numbers finance actually reports on, back the model with a pivot table or a defined formula, and use the AI for exploration and plain-language access. Don't let the model be the system of record for an exact figure yet. This is the Chapter 9 trust problem, live in their business.
Not done yet. This is the reasoning. The rewrite is a separate task when we greenlight it.
Session 1 becomes "one place for everything" as a Drive folder of structured exports, not a warehouse to choose and buy. More honest for a no-IT org, and something they walk out already using.
Prerequisites shift. The "Power BI Copilot / Fabric" line drops to optional. The real prereqs are a structured export from each source and a named data owner who'll run the daily habit.
The warehouse-first framing in the current sessions and case-studies pages still holds as the destination. We're just honest that the road there starts as a folder, and only becomes a warehouse when a source's manual dump earns the connector.