The practical small-business data stack for 2026: a build order

For most small and mid-sized organisations in 2026, a practical data stack has four layers: GA4 or an equivalent for website behaviour, a CRM as the single record of customers, server-side tracking to keep measurement honest, and a small warehouse only once reporting outgrows the tools themselves. Build them in that order, keep the data clean, and add AI summaries last. Everything else is optional.

Why do spreadsheets stop working?

Almost every organisation we meet starts the same way: a sales spreadsheet, an accounting export, a marketing report someone assembles by hand each month, and an owner whose gut feel fills in the gaps. This is not a bad starting point. Gut feel built the business, and a spreadsheet is honest about what it is.

The trouble arrives quietly. Two spreadsheets disagree about last quarter's revenue and nobody knows which is right. The person who maintained the report leaves. A number gets pasted over a formula. The monthly report describes a month that ended three weeks ago, so decisions are made on stale information or no information at all. None of these are dramatic failures; they are small frictions that compound until the owner stops trusting the numbers and reverts entirely to instinct.

The fix is not a bigger spreadsheet. It is moving each kind of data into a system designed to hold it, then connecting those systems so one version of each number exists.

What belongs in the stack in 2026?

The practical stack for a small or mid-sized organisation has stayed remarkably stable while the tools inside it improved. Website and app behaviour lives in an analytics platform, GA4 being the default for most. Customers, deals and conversations live in a CRM: HubSpot, Pipedrive, Zoho, or whichever your team will actually use. Server-side tagging sits between your site and the ad and analytics platforms, restoring the accuracy that browser privacy features and ad blockers have eroded. And when questions start spanning systems, a lightweight warehouse joins everything in one queryable place.

Notice what is absent: no streaming pipelines, no data lake, no ten-tool "modern data stack" diagram. Those exist for organisations with problems most small businesses do not have. The measure of a good stack is not how much it resembles a conference talk; it is whether the owner can answer their five most important questions in under a minute, from numbers everyone trusts.

When is a warehouse worth it, and when is it not?

A warehouse such as BigQuery is worth it in three situations. First, when your questions span systems: which marketing campaigns produce customers who stay, which requires joining ad data, analytics and the CRM. Second, when you need history that your tools discard or make awkward to reach; GA4 in particular rewards this, since it exports natively to BigQuery and the raw event data outlives the interface's retention windows. Third, when you want AI to work with your data, because a warehouse gives it one clean, structured place to look.

A warehouse is not worth it when it would be a trophy. If your CRM can already answer your pipeline questions and your analytics can answer your traffic questions, wiring them into a warehouse adds maintenance without adding insight. It is also not worth it before the inputs are clean: a warehouse full of duplicate contacts and untagged campaigns just centralises the mess. And it is never worth it as a first step. We have unwound more premature warehouses than we have built overdue ones.

The honest test: write down the three questions you cannot currently answer. If each can be answered inside a tool you already own, you do not need a warehouse yet. If they all require joining sources, you probably do.

What makes a dashboard people actually read?

Most dashboards are built once, admired once, and never opened again. The pattern behind the ones that survive is consistent: they are small, they are opinionated, and they are tied to decisions.

Small means a dozen numbers or fewer, not forty charts. Opinionated means each number carries a target or a comparison, so the reader knows instantly whether it is good news. Tied to decisions means every metric has an owner and an action: if this number moves, this person does that thing. A chart of sessions by device type fails this test for most businesses; leads this week against the same week last year, cost per qualified lead, and revenue against plan usually pass it.

Vanity reporting is the opposite: metrics chosen because they are available and flattering rather than actionable. Followers, impressions, pageviews and traffic totals have their place inside a marketing team's working view, but they do not belong on the page an owner reads on Monday morning. Our rule in performance marketing engagements is blunt: if a metric cannot change a decision, it does not get a tile.

A dashboard nobody reads is a screensaver with a maintenance bill.

Are AI summaries of business data actually useful?

By 2026, yes, with one large caveat. Current language models are good at exactly the task most owners want: reading a week of numbers and saying, in plain English, what changed, what looks unusual, and what deserves attention. A short AI-written brief every Monday morning gets read in a way a dashboard often does not, because it arrives, it is short, and it speaks in sentences rather than axes.

The caveat is that AI narrates whatever data it is given, fluently and confidently, whether or not that data is right. If your CRM holds duplicate contacts, if half your campaigns are untagged, if refunds never make it back into the revenue figure, the summary will be polished and wrong, and its polish makes the wrongness more dangerous than a messy spreadsheet ever was. Clean data quietly compounds; messy data quietly lies. This is why AI sits last in the build order, not first, and why in our AI development work the unglamorous data-cleanup phase always precedes the model.

Looking slightly ahead: the tooling is moving from summaries toward agentic analytics, where you ask a question in plain language and an agent queries the warehouse, checks its own work, and answers directly. The early versions are promising and the direction is clear, but treat vendor demos with caution. Agents inherit every flaw in the underlying data, and the organisations that will benefit first are the ones whose stack is already clean. Preparing for that future looks exactly like the build order below.

Who owns the data, and what do the laws expect?

Two principles keep small organisations out of trouble. The first is ownership: your customer data should live in accounts you control, exportable in open formats, never held hostage inside a vendor's proprietary silo or an agency's login. At OlDevs, clients own all code, designs, accounts and IP as a matter of policy, and we hold the same line on data: if you cannot leave with it, you do not really own it.

The second is compliance. In Canada, PIPEDA sets the federal baseline for handling personal information, Quebec's Law 25 adds materially stricter consent and transparency requirements for anyone with customers in that province, and British Columbia and Alberta have their own private-sector acts. Sell into the United States and a growing patchwork of state laws, California's chief among them, applies as well. The details vary; the common thread does not: collect only what you need, tell people plainly what you collect, honour consent choices including in your tagging, and be able to delete someone's data when asked. A stack built on these habits from day one barely notices the regulation. A stack retrofitted under complaint notices little else. Consent mode, data retention and regional storage are technical details we treat as part of the build, not an afterthought.

How OlDevs builds this, in order

We have been building software and measurement for organisations since 2014, and the sequence that works for a non-technical owner is the same one we follow ourselves:

1. Pick one CRM and make it the single record of customers. Migrate the spreadsheet in, deduplicate, and retire the spreadsheet.
2. Set up GA4 properly: conversions defined, internal traffic excluded, campaigns tagged consistently.
3. Connect your ad platforms and email tool to the CRM so a lead's source survives all the way to the closed deal.
4. Add server-side tagging once advertising accuracy starts to matter.
5. Build one small dashboard, a dozen numbers with owners and targets.
6. Add a warehouse only when questions genuinely span systems.
7. Layer AI summaries, and eventually agentic analytics, on top of data you already trust.

Each step is useful on its own, so you can stop at any point and still be better off, and each produces something you own outright. As with all our work, you get one accountable team, a working demo every week, and a stack documented well enough that you are never dependent on us to understand your own numbers.

If your reporting still lives in spreadsheets, or your dashboards exist but nobody reads them, we can map this build order onto your organisation, from analytics cleanup through custom reporting tools where off-the-shelf falls short. Tell us where the numbers hurt and we will reply within one business day. Request a quote.