You don't need big data to make data-driven decisions
Most companies think a data platform is for enterprises with terabytes of data and dedicated data teams. It is not.
There is a story about Ronald Read, a janitor and gas station attendant from Vermont who died in 2014 and left behind an $8 million estate. He built it by investing small amounts consistently over decades. No hedge fund. No inheritance. No financial team. Just discipline and a system.
The reaction when people hear this story is usually the same: that is the exception, not the rule. You need capital to invest seriously. You need scale to make it worth the effort.
The same assumption exists in data. Companies think they need terabytes of data, a dedicated data team and an enterprise warehouse contract before a data platform makes sense. So they wait. They run on spreadsheets and gut feeling until they are big enough to justify the investment. By then, they have made years of decisions without the evidence that would have made those decisions better.
The assumption is wrong in investing. It is equally wrong in data.
What a data platform actually is
Strip away the marketing and a data platform is a system that collects information from multiple sources, puts it in one place and makes it queryable. That is it.
The enterprise version of this involves petabytes of clickstream data, dozens of engineers and a warehouse bill that could fund a small startup. That version exists because enterprises have petabytes of clickstream data and dozens of engineers to manage it.
A small company has different data. Not less valuable data. Different data.
A three-person consultancy has contract revenue, project costs, team time, content performance across LinkedIn and Medium, newsletter subscribers and website traffic from Google Search Console. None of these sources individually tells the full story.
A client that looks profitable on revenue alone looks different when project costs and time are in the same query. A LinkedIn post that gets strong engagement looks different when you can see whether it actually drove traffic to the article it referenced.
The question is not whether the data is big enough. The question is whether having it in one place would change any decisions.
What we built and what it costs
Northgrain is a three-person data engineering consultancy. We built our own data platform because the alternative, five disconnected tabs and manual reconciliation every time a business question came up, was costing more in time than the platform costs to run.
The stack:
- Dagster for orchestration
- dltHub for ingestion
- self-hosted ClickHouse for storage
- dbt for transformation
The full platform runs on a VPS costing about $20 per month.
The sources include Google Search Console, Google Analytics 4, LinkedIn analytics, Medium stats, Resend newsletter data, client contracts, project expenses and team costs.
The reason for each stack choice was practical. Dagster's asset-based model maps naturally onto keeping specific datasets fresh rather than treating every workflow as an isolated scheduled job. dltHub is Python-native and integrates cleanly without a separate managed service. ClickHouse on a modest VPS handles our data volumes without becoming the constraint and keeps sensitive business data under our control.
None of these are exotic choices. They are the same tools we recommend to clients, running on real operational data. Every architectural decision gets tested before it gets recommended.
What the data shows that spreadsheets did not
The clearest example is the relationship between LinkedIn and Medium.
LinkedIn posts that reference an article drive a measurable traffic spike on Medium within 24 to 48 hours of posting. The inverse is not true. Medium articles do not drive LinkedIn engagement in any consistent way.
Without the data connected, this relationship is invisible. With it, the content strategy becomes clear: LinkedIn is the distribution layer, Medium is the depth layer. Posts that perform well on LinkedIn justify the time investment in a full article. The platform made this visible without manual reconciliation across separate tabs.
LinkedIn reached 549,000 impressions over 90 days, up 28,369% compared with the prior period.
LinkedIn content performance over the 90 days ending 3 August 2026.
Medium tracked that growth month by month. May 2026 showed 596 views and 276 reads. June reached 2,600 views and 1,400 reads, roughly four times the views and five times the reads in a single month. July settled at 916 views and 365 reads, still above the May baseline.
Medium performance from May to July 2026. June followed the strongest wave of LinkedIn distribution.
The content classification model reinforces this. Every piece of content gets scored on format type, estimated production time, engagement rate and traffic movement. The output ranks formats by the return they produce relative to the time they consume.
Long-form technical articles with code examples consistently outperform opinion pieces on read-to-view ratio. That insight changed how production time gets allocated.
On the business side, contract profitability looks different when time, expenses and revenue are in the same query layer. A project that generates strong revenue but consumes disproportionate team time shows up differently from one that is smaller but more efficient. That visibility now informs which types of work to prioritise and which to price differently.
The actual barrier to entry
The reason most small companies do not have a data platform is not cost. A self-hosted stack running on $20 per month of infrastructure is available to any company with a technical person who can set it up. The reason is the assumption that it is not worth it yet.
That assumption has a compounding cost. Every month of decisions made without connected data is a month where the relationship between LinkedIn and Medium is invisible, contract profitability is estimated rather than calculated and content strategy is based on feel rather than evidence.
The platform does not need to be sophisticated to be valuable. It needs to exist.
Ronald Read did not wait until he had enough money to make investing worth it. He invested what he had consistently and let the system do the work. The parallel for data is not perfect, but the logic is the same: waiting for scale before building the system means the system is never there when the early decisions are made. Those decisions do not get cheaper to unmake later.
What this looks like outside a consultancy
The stack above reflects the needs of a consultancy tracking content, contracts and costs. The principle applies more broadly.
A five-person SaaS company has product usage data, subscription revenue, support tickets and churn. Connecting those sources answers questions that no single source can: which features correlate with retention, which support issues precede cancellations and which acquisition channels produce the highest lifetime value customers.
A small e-commerce brand has order data, ad spend, email performance and inventory. Connected, they answer which campaigns produce profitable customers rather than just customers.
The data is already there. Most small companies generate enough operational data to support real analytical decisions. The gap is not the data. It is the system that connects it.
Where to start
The mistake most small companies make when they decide to build is starting with the infrastructure. The right starting point is the question.
What decision, if you had better information, would you make differently?
Start there. Identify which sources contain the relevant data. Build the minimum pipeline that connects them. Answer the question. Then ask the next one.
A platform built this way, question by question, stays grounded in decisions rather than growing into infrastructure that nobody uses. It also stays cheap. The $20 per month VPS running ClickHouse started with two data sources and one question. The question got answered. The platform grew from there.
The enterprise version of this costs millions. The small-company version costs about twenty dollars a month and the discipline to build it before it feels necessary.
"Okay, but this probably takes months and costs a fortune"
It does not have to.
The ingestion pipelines, transformation layer and scoring models described above can fit into a fixed-scope implementation. A Northgrain Data Engineering Sprint is a 3 to 6 week engagement that delivers one defined outcome, validates it and hands it over.
If the questions in this article sound familiar and you want them answered about your own business rather than ours, the Data Engineering Sprint is designed for that situation.
