Most analytics projects do not fail at the dashboard. They fail because nobody agreed what a customer is, or which of the four systems holding revenue is correct, and the dashboard then reports a confident number that two departments both know is wrong. The modelling work that prevents this is unglamorous, comes first, and is what separates a useful analytics engagement from an expensive screenshot.
ScienceSoft’s own stated range. Honest, and useless until you know what moves you along it.
Not the dashboard. Two departments disagreeing on what revenue means.
Metrics defined once, in code, versioned. Every answer inherits them.
Layer it over governed data, never instead of it. A fluent answer is not a correct one.
On this page
- How much do data analytics services cost?
- What else moves the number
- Can ChatGPT do data analysis?
- What we build
- The data analytics services Sthenos sells
- The words a data proposal will use at you
- The data technologies this site already works with
- What lands on your side of the table
- How a data engagement runs, step by step
- What to ask any data analytics vendor
- More to ask, about the platform and the contract
- Frequently asked questions
- Data analytics with Sthenos
- More on data and analytics
- Talk to our engineers
How much do data analytics services cost?
Google lists this as the second question on this search, and one competitor answers it publicly, so we will point at that rather than pretend the range is secret. ScienceSoft, which ranks on page one for this term, publishes $10,000 to $1,000,000+ depending on service type and complexity. That span is honest and also useless on its own, so here is what moves you along it.
| Driver | Cheaper end | Expensive end |
|---|---|---|
| Sources | One or two systems with clean APIs | Many systems, some legacy, some only exporting files overnight |
| Definitions | The business already agrees what the metrics mean | Every department has its own definition of revenue and churn |
| History | Report from today forward | Backfill and reconcile years of inconsistent history |
| Latency | Daily refresh | Streaming, with correctness guarantees under failure |
| Governance | Internal reporting only | Regulated data, lineage, retention and access audits |
| Who runs it after | Your team owns the models | Nobody owns them, so it silently rots |
What else moves the number
The six rows above are the drivers that move the estimate most. Four more sit underneath them and get missed in most scoping conversations. None of them carries a figure here, because a figure without your scope attached to it is decoration.
- The quality of the sources, not only how many there are. Counting systems is the easy half. A documented API is cheap to read. An undocumented overnight export, duplicate customer records and a column whose meaning quietly changed during an old migration are each their own piece of work, and none of them is visible from a count.
- Data volume and its growth rate. Volume mostly moves what the platform costs to run rather than what it costs to build, which is why it belongs in the operating budget conversation and not the build quote. Growth rate matters more than today’s size, because it decides how soon the first design stops fitting.
- How many people use it, and how. A small analyst team querying a warehouse is a different sizing problem from a whole workforce opening an embedded dashboard. User count also drives the access control work, because row level filtering only becomes necessary once the audience is wider than the team that owns the data.
- How much of the existing reporting has to come with you. Rebuilding every legacy report one for one is almost always the wrong answer and always the expensive one. The inventory of what people actually open is worth doing before the estimate, not after.
The engineering detail behind all of these is on the sibling page, big data and analytics, which publishes a band for a first warehouse and reporting layer and the reference architecture the estimate is built from.
Can ChatGPT do data analysis?
On a clean, small dataset that fits in a prompt, genuinely yes, and it is very good at the exploratory pass. That is not what a data analytics engagement is for.
The difficulty in real organisations is upstream of analysis: the data is spread across systems, the join keys disagree, the same field means different things in two places, and the history contains a migration that changed the meaning of a column three years ago. A language model given that mess will produce a fluent answer, and there is no marker on the output distinguishing a correct one from a confident one. The value of a modelled warehouse is precisely that the definitions are settled once, visibly, and every answer inherits them.
Where it genuinely helps: drafting transformations, explaining unfamiliar schemas, and letting non-technical users ask questions of a warehouse that has already been modelled properly. Layer it on top of governed data, not instead of it.
What we build
Data platform
Ingestion, a warehouse or lakehouse, transformation with tests, and orchestration that alerts when a load fails rather than serving stale numbers silently.
Semantic layer
Metric definitions written once, in code, versioned. This is the artefact that stops two dashboards disagreeing.
Reporting
Dashboards people actually open, which usually means fewer of them, answering questions someone named actually asks.
Quality and observability
Freshness, volume and schema-drift checks, so you find out before the board meeting rather than during it.
Governance
Access by role, lineage from source to number, retention rules, and deletion that reaches every copy.
Figure 1. From a source system to a dashboard
Caption: the two bands are the parts that decide whether anyone trusts the output, and they run across every stage rather than being bolted on at the end. Each stage named here is described in the sections below. The diagram carries no figure, because a duration or a count without your source list attached to it would be decoration.
The data analytics services Sthenos sells
Data work is bought in pieces, and which piece you need depends on where the problem actually sits. The seven groups below are how Sthenos splits it. Each links to the page on this site that sells the surrounding capability.
Data strategy and governance
What the organisation is allowed to hold, who may read which rows, how long each dataset is kept, and who owns the definition of a metric. Buy this first when the honest problem is that nobody can say who decides what revenue means. Related: IT consulting, cybersecurity.
Data engineering and pipelines, batch and streaming, ELT and ETL
Getting data out of the systems that produce it and into somewhere it can be modelled: scheduled batch loads for most sources, streaming where a decision genuinely cannot wait for the next load, and the transformation logic in between. Related: big data development, DevOps, and the pipeline layers on big data and analytics.
Warehouse and lakehouse
The storage layer: a raw landing area, a modelled serving area, and a deliberate decision about which of the two a given question is answered from. Related: cloud computing, cloud migration and optimization.
Business intelligence and dashboards
Reports a decision maker opens, which usually means fewer dashboards rather than more. Related: Microsoft platform services, which covers the reporting stack most enterprises already own.
Advanced analytics and machine learning
Predictive and prescriptive work on top of a governed platform, rather than a model built on data nobody has modelled. Related: data science, AI and machine learning, agentic AI.
Data quality and master data
Freshness, volume and schema drift checks, and one agreed record for the entities every system holds its own version of: customer, product, site, employee. This is the section of the work that decides whether anyone trusts the output.
Data platform operations
Running it afterwards: orchestration that alerts when a load fails instead of serving stale numbers silently, cost control on storage and query, access reviews, and a named owner for every pipeline. Related: managed services, infrastructure management, the production readiness checklist.
The words a data proposal will use at you
None of these terms is difficult, and knowing what each one means is usually enough to tell a considered design from a shopping list. The longer engineering treatment, including dimensional modelling and grain, is on big data and analytics.
Data warehouse, data lake and lakehouse
A warehouse stores structured, modelled data ready for reporting. A lake stores raw data in its original form for exploration and machine learning. A lakehouse puts warehouse behaviour, table definitions, schema enforcement and transactional updates, directly on lake storage so one copy serves both jobs. Most organisations end up with both patterns whatever they call them.
ELT and ETL
ETL transforms data before loading it. ELT loads it raw into the warehouse first and transforms it there. ELT became the default when cloud warehouses made compute elastic, and its practical advantage is that the raw data is already in the platform on the day somebody discovers the transformation was wrong.
Change data capture
Reading a source database change log so the platform receives inserts, updates and deletes as they happen instead of re-reading whole tables on a schedule. It solves load on the source system and it solves deletes, which a periodic full extract cannot see because the row is simply gone.
Streaming and batch
Batch processes data in scheduled groups. Streaming processes each event as it arrives, and costs more to build and considerably more to operate because late arriving events, replay and correctness under failure all have to be designed. The question is not whether the data could be real time but whether a decision changes between one load and the next.
The semantic layer
One place where every metric is defined, in code, versioned, and read by every reporting tool rather than reimplemented inside each of them. It is already the second item in what we build above, and it is the artefact that stops two dashboards disagreeing.
Data catalog and lineage
A catalog is the inventory of which datasets exist, what each column means, who owns it and how sensitive it is. Lineage is the map from a number on a dashboard back through every transformation to the source column. Lineage is the one to ask for a demonstration of, because it cannot be faked.
Row level security and column masking
Row level security filters what a user sees inside a shared table, so a regional manager opening the same dashboard as head office sees only their own region. Column masking hides a sensitive field from users who do not need it. Both belong in the platform, because a control implemented per dashboard will be missing from the next dashboard.
Data quality checks and data SLAs
Quality checks are assertions that run with every load: freshness, volume, schema and business rules such as no negative quantities. A data SLA is the agreement about what happens when one fails, including who is told, how fast, and whether the dashboard shows stale data or shows nothing at all.
The data technologies this site already works with
Every product named below is named because another page on sthenostechnologies.com already says this company works with it, and that page is linked beside it. Where this site publishes no product for a category, the category is described and no product is named.
Streaming platforms, transformation frameworks, the independent cloud data warehouses sold as separate products and every business intelligence tool other than the two above are described here as categories and named nowhere, because no page on this site claims one. If a specific product decides your shortlist, ask in the first conversation rather than reading a logo grid.
What lands on your side of the table
Every item below restates something Sthenos already publishes. Nothing is promised here that is not promised elsewhere on this site.
- The repository and the cloud accounts, in your name from the first commit, with no licence back to us and no dependency on Sthenos continuing to exist, as the About page states it.
- A costed roadmap before any build starts. Where the scope is clear we quote a fixed price for a defined outcome.
- The data model, written down, so it can be checked against how the business actually works before any code depends on it.
- Pipeline code with its tests, and orchestration that alerts on failure rather than serving stale numbers silently.
- Metric definitions in code, versioned. The semantic layer, so two dashboards cannot disagree without somebody having changed a definition somewhere reviewable.
- Dashboards people actually open, answering questions somebody named actually asks.
- Freshness, volume and schema drift checks, and lineage from source to number, so a wrong figure can be traced rather than argued about.
- Access by role, retention rules and deletion that reaches every copy.
- A platform your own engineers can run once we hand it over, which is the standard our Maryland page already sets, with monitoring and maintenance afterwards if you would rather we kept running it.
The governance controls, and what each one does
Every control below is defined further up this page, and every one of them belongs in the platform rather than inside an individual dashboard.
How a data engagement runs, step by step
Sthenos works in two week sprints, so working software arrives every two weeks rather than as a reveal at the end. No stage below carries a duration, because a duration without your source count attached to it would be decoration.
- Definitions and source inventoryTwo lists get made before any pipeline is written: every system holding data in scope, with how it can be read and who owns it, and every metric you intend to report, with the person allowed to decide what it means. Disagreement surfaces here, which is the cheapest place for it to surface.
- Architecture and data modelWhich cloud, batch or streaming per source, where raw data lands, what the warehouse grain is, and which controls governance has to enforce. Produces the architecture, the model and a costed roadmap.
- Pipelines, transformation and testsThe first sprint deliberately takes one unglamorous source end to end, because a thin slice that reaches a real number proves the pattern before ten sources are built on it.
- Semantic layer and reportingMetric definitions written once and read by the reporting tool, then the smallest set of dashboards that answers the questions named in stage one, reviewed by the person who owns the definition rather than only by whoever asked for the chart.
- Handover and operationAccess reviews, lineage documentation, cost controls on storage and query, and a named owner for every pipeline. The platform is built so your own engineers can run it once we hand it over.
What to ask any data analytics vendor
- Who decides what a metric means? If the answer is the vendor, you will get numbers nobody in the business trusts.
- Show me a lineage view. From a number on a dashboard back to the source column. If they cannot, nobody can debug a wrong figure later.
- What happens when a source changes shape? Silent breakage is the norm without explicit schema checks.
- Will my team be able to add a metric without you? Ask for the actual pull request that adding one would require.
- What did you refuse to build? Every honest analytics engagement includes talking someone out of a real-time dashboard they do not need.
More to ask, about the platform and the contract
The five questions above are about the analytics. These five are about the engagement, and every one of them is already published by this company somewhere else on this site, so you can put all of them to us as well as to the other firms on your list.
- What documentation is a contractual deliverable? Not what they promise to write. The distinction is the advice on our software outsourcing page.
- Who reviews the code, and can that person veto a merge? Reviewers who are the same people who wrote the code are not reviewers.
- Who is paged when a load fails at 2am? Establish it before you sign, not after the first incident.
- Are there named engineers on the contract, with a notice clause if they change? The A team pitching and the B team delivering is a known pattern and a contract can prevent it.
- What would make you decline this requirement? A firm that has never declined anything is telling you something about how it scopes.
Frequently asked questions
What is the difference between a data warehouse and a data lake?
A warehouse stores structured, modelled data ready for reporting. A lake stores raw data in its original form for exploration and machine learning. Most organisations end up with both, and the mistake is building the lake first and never modelling anything.
Do we need a data warehouse if we already have Power BI?
Often yes. Power BI reporting straight off production systems slows those systems and breaks whenever a source schema changes. A warehouse gives reporting its own stable, modelled copy, and the semantic layer on top of it is what stops two Power BI reports disagreeing.
How long before we see useful dashboards?
Six to ten weeks for the first genuinely trustworthy dashboard. The delay is almost never the visualisation, it is agreeing what the numbers mean across departments that define them differently.
What is a lakehouse, and do we need one?
A lakehouse puts warehouse behaviour, table definitions, schema enforcement and transactional updates, directly on lake storage, so one copy of the data serves both exploration and reporting. You need one when you already have both a lake and a warehouse and they have started to disagree.
Can you build real time dashboards?
Yes, and the more useful conversation is whether you need one. Streaming costs more to build and considerably more to run, because late arriving events, replay and correctness under failure all have to be designed. The test is whether a decision actually changes between one load and the next.
How do you handle data security and compliance?
Access by role, row level filtering inside shared tables, encryption in transit and at rest, retention rules and deletion that reaches every copy, plus lineage so an auditor can trace a number. Where you are bound by HIPAA, SOC 2, GDPR or CCPA we build to those controls and hand over the evidence trail. Sthenos is not SOC 2 attested and holds no attestation of its own.
Do you migrate legacy reports?
Yes. Before rebuilding we inventory which reports are actually opened, which duplicate each other under different names, and whose numbers already disagree, then rebuild those on the modelled layer.
Who owns the data model and the code when the engagement ends?
You do, entirely, from the first commit. The repository and the cloud accounts are in your name, with no licence back to us, and the platform is built so your own engineers can run it once we hand it over.
Data analytics with Sthenos
We build data platforms and reporting for organisations across Maryland and the Washington DC region, delivered through an established engineering partnership with NeoSOFT. We start with definitions and lineage rather than with a dashboard, because the dashboard is the cheap part and the disagreement about what the numbers mean is the expensive one. To scope a platform or fix reporting nobody currently trusts, talk to our engineers. Related: our big data and analytics practice.
More on data and analytics
Services: Big data and analytics, Big data development, Data science, AI and machine learning, Agentic AI, DevOps.
Platforms: AWS, Microsoft Azure, Google Cloud, Microsoft platform services, Microsoft 365 and SharePoint, Cloud computing.
Before you buy: Production readiness checklist, Production readiness audit, Cybersecurity, How Sthenos works, rates and ownership, Talk to our engineers.
Ready to scope it? Bring the list of systems and the metrics you need to report on, and we will tell you what the platform behind them would involve. Talk to our engineers.