It's 7:40 Monday morning and Maria, ops lead at a 40-person services firm, is performing the ritual. Export from the CRM. Export from billing. Export from the project tracker. Paste into the master spreadsheet, VLOOKUP the client names that don't quite match, and pray the totals land before the 9 a.m. owner call.
The ritual eats five hours a week when nothing goes wrong, which is half the weeks. The spreadsheet has a backup, and the backup has a backup; the last corruption incident is still mentioned in whispers.
If you want to build a first data pipeline for a small business, this is the situation you're fixing, and the fix is far less exotic than the word "pipeline" suggests: pull the data on a schedule, land it raw, model it once, and show it somewhere people look. A competent first version takes about a week, runs on boring technology, and costs less per month than the coffee budget. Here's the whole build.
Monday Morning: Three Exports and a VLOOKUP
Start by respecting the ritual. Maria's spreadsheet exists because it answers the question the owner actually asks every week: "How are we doing?" The three systems each hold a third of the answer, none of them talk to each other, and the export buttons are right there. The manual pipeline is a rational response to the tools available.
This matters because your first pipeline will fail socially if it answers a different question than the ritual answered. Don't build the dashboard you find interesting. Build the one that makes the 9 a.m. call work, and earn the right to build the second one later.
What a First Data Pipeline Actually Is (Small Edition)
Strip the enterprise jargon and a pipeline is four parts:
- Pull. A script grabs data from each source on a schedule, via API where one exists and via scheduled CSV export emailed to a robot address where it doesn't.
- Land. The raw data goes into a database exactly as received, untouched. Raw first, always. When your model turns out to be wrong, and the first one always is, you rebuild from the raw copy instead of re-pulling history you can't get back.
- Model. A second step reshapes the raw tables into the one table that answers the weekly question. Clients, invoices, hours, one row per thing the business thinks in.
- Show. A dashboard reads the modeled table. That's it. That's a pipeline.
Four parts, no buzzwords, and each part is a thing you can hold in your head. If someone describes a small-business pipeline with more nouns than that, they're selling something.
The Boring Starter Stack
For a business this size, the stack that wins is aggressively unglamorous: a scheduled script (cron, Task Scheduler, or a tiny cloud function), one Postgres database as the home for everything, and a Metabase-style dashboard tool pointed at the modeled table.
Why boring wins here: the stack will be maintained by whoever is available, possibly you, possibly a contractor twice a year, possibly nobody. Every clever component you add is a future 2 a.m. mystery for a person who didn't choose it. Postgres will happily hold this company's entire data history on a $20-a-month instance with room left over for your doubts. Cron has been running scheduled jobs since before some of your sources existed. The dashboard tool is free and non-technical people can click around in it without breaking anything.
Resist the urge to reach for the famous orchestration frameworks. Airflow is a wonderful tool for teams with a data platform. You have Maria.
The Week-One Build, Day by Day
This is the schedule that actually fits in five working days:
- Day 1: Raw pulls land. Get the three sources flowing into raw tables on a schedule, even if the data looks horrible. Especially then. Log every run so failures are visible instead of silent.
- Days 2 and 3: The one table. Build the modeled table that answers the weekly question. This is where the real work is: matching "Acme, Inc." to "ACME INC" to "acme inc (do not use)", handling the invoice that exists in billing but not the CRM, deciding what the truth is when sources disagree. Budget most of your week here.
- Day 4: The dashboard. Five tiles, not fifty. The three numbers from the Monday meeting, plus two trends. If a tile doesn't answer a question someone asks out loud, delete it.
- Day 5: Alerts and the README. Wire a notification when a pull fails, and write the one-page README: what runs, when, where the logs are, and what to do when it breaks. The README is the difference between a pipeline and a haunting.
Mistakes That Kill First Pipelines
Having watched a few of these die:
- Modeling everything up front. You build twelve beautiful modeled tables, three get used, and the other nine rot while someone is afraid to delete them. Model the one question; add the rest when someone actually asks.
- Real-time fever. Nobody making decisions at a 40-person firm needs streaming data. They need Monday's numbers to be right. Hourly syncs are already a luxury; daily is often plenty.
- Five sources when one answers the question. Every source is a maintenance subscription you pay forever. Start with the two or three that feed the weekly question and let the rest wait.
- No owner for failures. A pipeline with no named human who gets the failure alert is a pipeline that's already broken; you just haven't noticed. Name the human. Buy them coffee.
A related judgment call is whether a given step needs AI at all. Most of this pipeline is deterministic glue, and as we argue in AI agent vs. boring script, if the logic is deterministic, don't pay tokens for it. LLMs earn their keep in adjacent territory, like the messy document extraction covered in LLM document processing in the real world or the agent patterns in shipping AI agents to production. Your first pipeline is neither, and it's better for it.
After Week One: Growing Without Rewriting
The boring stack has a growth path, which is why it's boring and not dead-end. When the second dashboard question appears, you add a source and a modeled table; nothing existing gets touched. When the modeled layer gets big enough that changes are scary, a tool like dbt earns its keep by making the transformations versioned and testable. When the firm hires its first data person, they inherit raw history, a working system, and a README, which makes you the best thing that ever happened to them.
On the other side, the numbers are satisfying: the five-hour ritual typically drops to a half-hour of sanity-checking, the Monday call starts arguing about decisions instead of data, and the master spreadsheet is quietly retired to a read-only archive, where it can hurt no one ever again.
Start with one question, land everything raw, and write the README. The pipeline you build in a week is the thin end of a very useful wedge.