Build it yourself, or buy the layer on top
If you already have a data warehouse, you do not need Dema to report on sales. Where it earns its place is the layer above: measurement logic, profitability modelling, forecasting and agents that act. This page is about where that line sits.
Keep building it yourself, if this is the job
If what you need is sales, revenue and order reporting, build it in your warehouse. Most companies at any scale already have one, and Dema is not a replacement for it. A warehouse is usually the better home for finance, BI and bookkeeping, where the priority is being fully reconcilable and historically correct: every figure traceable, every restatement auditable. That is a different requirement from deciding what to spend next week, and it is one your own team can meet better than a vendor can, because they know your edge cases.
The break point is reporting versus deciding
Building gets hard when the ambition moves from describing what happened to choosing what to do next, and harder again when you want software to do the choosing. That is not a dashboard problem. It needs a semantic layer, attribution logic, profitability modelling, forecasting, agent tooling, data access for those agents, workflow automation, and something reliable enough to execute against your ad accounts.
One question that shows where the line is
“What is the optimal marketing plan for Germany next week? Which products should we increase or exclude in PMax to improve profitability, without dropping products that have low sell-through predictions? Summarise the recommended actions, generate the weekly deck from it, schedule it, and share it with marketing and buying. And confirm with me before executing anything to Google.” Nothing in that sentence is exotic. But answering it needs measurement logic, margin after real costs, a sell-through forecast, scheduling, document generation, permissions and an approval gate on an outbound write. Every one of those is a component someone has to build, own and keep running.
What you would be taking on
Not reasons you can't. Reasons it costs more than it first looks.
A semantic layer, before anything else
Agents and analysts both need one definition of ad spend, net sales and contribution margin, not fifteen columns that could each be it. Building that means agreeing definitions across finance, marketing and buying, encoding them once, and defending them as the business changes. It is the least glamorous part and the part everything else depends on.
Profit logic that survives returns
Cost of goods is the easy half. Shipping, toll, pick-and-pack and transaction fees vary by market, warehouse and fulfilment route, and returns arrive weeks after the order, so a margin figure that books returns when they land is systematically wrong for the most recent period. Expected-return modelling per product is a project in itself.
Measurement, not just attribution
Reading platform numbers is straightforward. Deciding how much of each to believe is not: that needs geo-based experiments, a marketing mix model, and something reconciling their answers into one number you can budget against. This is a data science function, not an engineering ticket.
Text-to-SQL is the part people underestimate
The plan is usually "point an LLM at the warehouse". A 2026 benchmark of enterprise text-to-SQL found the best system answered under a quarter of questions correctly even when handed curated documentation of the business's own metric definitions. Company conventions are exactly where SQL generation fails, and in commerce analytics those conventions are the whole job.
Agents that belong to the company, not a laptop
Claude, Cursor and ChatGPT are excellent, and they are provisioned per user. Getting from one analyst's clever prompt to something running on a schedule, with its own scoped access to Google Ads and Shopify, memory that persists, an approval gate before it writes, and a team of non-technical people relying on it: that is a platform, and it is the gap between a demo and a system.
Somebody on call
Once buying reorders against a forecast and an agent adjusts budgets on a schedule, a silent pipeline failure is a commercial event rather than a data-quality ticket. Someone has to own uptime, run the upgrades and answer at 7am on Black Friday.
Where each one is genuinely stronger
Rows where building in-house wins are marked as such. There are more of them than a vendor page usually admits.
Statutory and audited reporting
Data you alone understand
Total control and no vendor risk
Semantic layer for agents and analysts
Profit after operational cost and returns
Attribution, MMM and incrementality
Inventory and sell-through forecasting
Agent platform
Time to first decision
Ongoing cost
| Dema | Build in-house | |
|---|---|---|
| Statutory and audited reporting | Not what it is for. | Your warehouse, reconciled to the ledger and historically restatable. Keep this in-house. |
| Data you alone understand | Needs modelling with you before it is useful. | Your team already knows the edge cases in your returns, VAT, cancellations and product attributes. Nobody models that faster than you do. |
| Total control and no vendor risk | A dependency, honestly. | You own the roadmap, the schema and the exit. For some organisations that is decisive on its own. |
| Semantic layer for agents and analysts | 215 metrics and 110 dimensions, each defined once and combinable almost freely. | Buildable (dbt or a warehouse semantic layer), but the definitions still have to be agreed and then defended over time. |
| Profit after operational cost and returns | GP3 per product, market and campaign, with rules-based fulfilment costs and actual plus estimated return rates. | The hardest single piece to get right, and the one most often postponed. |
| Attribution, MMM and incrementality | All three, reconciled, with test results calibrating the model and the attribution weights. | A data science team, or an open-source MMM plus the experiment design and analysis around it. |
| Inventory and sell-through forecasting | Sell-through forecasts per size and inventory as of any past date, in the same model as spend. | A forecasting project, then ongoing accuracy work as ranges and seasons change. |
| Agent platform | Scoped tools and integrations, persistent memory, scheduling, app surfaces, approval gates, MCP execution. | The frameworks are available. The permissions, scheduling, sharing and audit around them are what takes the time. |
| Time to first decision | Most teams connected within a day; the long pole is agreeing cost data. | Quarters, realistically, for the layer above reporting. |
| Ongoing cost | A subscription, and a dependency. | Salaries across data engineering, data science and platform work, plus the opportunity cost of what that team is not doing. |
Written to be argued with. If you think a row is wrong for your situation, that is a good conversation to have on a call rather than a reason to distrust the page.
It is not all or nothing
The best setups we see are a combination. You keep a strong internal data foundation: returns, cancelled orders, VAT, product attributes, shipping costs, weights, finance reporting, the data-quality work that only you can do. Dema takes the forward-looking layer on top: commercial analytics, measurement, profitability, forecasting and agents. Think of it as a smorgasbord rather than a migration: you choose what to own and what to offload.
This works best when you have a strong technical partner in-house
That sounds like a caveat and it is meant as one. We want someone on your side who will argue with us about data definitions, accuracy and edge cases, and who can change the underlying data when it needs changing. The customers who get the most out of Dema are not the ones who outsourced understanding their data. They are the ones who understand it well and wanted to move faster on top of it.
Frequently asked questions
No, and we would not recommend that. Your warehouse is usually the right home for finance, BI, bookkeeping and historical reporting, where being reconcilable and restatable matters most. Dema reads from it (BigQuery, Snowflake, Databricks and Azure SQL are all supported) and adds the layer above: measurement logic, profitability modelling, forecasting and agents. If your warehouse already holds clean ad platform and order data, connecting it is often faster than connecting each source separately.
Because the hard part is not generating SQL, it is knowing which of your columns means what. A 2026 benchmark of enterprise text-to-SQL found the best system answered under a quarter of questions correctly even when it was given curated documentation of the business's own metric definitions, and metric definitions are precisely where commerce analytics lives. A semantic layer removes the step rather than improving it: the agent asks for a metric by a dimension, and the definition is already fixed. You can absolutely build that layer yourself. It is just the thing to build first, not last.
A semantic layer with agreed definitions; profit logic covering cost of goods, shipping, toll, pick-and-pack and transaction fees with expected returns modelled per product; attribution plus a marketing mix model plus geo experiment design and analysis; sell-through and inventory forecasting; and an agent platform with scoped permissions, scheduling, memory, sharing and approval gates. Then you own accuracy, uptime and upgrades for all of it. Any one piece is a reasonable project. The combination is a roadmap, and it competes with everything else your data team could be doing.
No. Most good data teams could build any individual piece of this, and some build several well. The question is whether it is the best use of them, and whether the parts that need continuous investment (measurement accuracy, forecast quality, agent tooling, being on call when an agent writes to an ad account) will keep getting that investment two years from now, when the team has other priorities. Plenty of companies conclude they would rather own the data foundation and buy the layer above it.
Connecting sources is quick: ad platforms and e-commerce platforms authenticate with OAuth in minutes each, and most teams are connected within a day. The part that takes longer is cost data (cost of goods, fulfilment rates and expected returns), because that is what turns revenue reporting into profit reporting, and it needs someone from finance rather than an API key. That work would be required in a build-it-yourself path too; it just tends to be discovered later.
Your sources and your warehouse are unchanged, because Dema reads from them rather than replacing them, and the GraphQL API on every plan means the modelled data is extractable while you are a customer. What you would lose is the modelling layer itself (the metric definitions, the attribution weighting, the forecasts and the agents), which is the thing you are buying. It is a real dependency and worth weighing honestly rather than being talked out of.
Own your data foundation. Let us handle the layer that has to keep moving.