Building Analytics and Fault Detection Software: Build or Buy at Your Portfolio Size
The threshold is automation vendor variety rather than building count. Under about 10 buildings on a single mainstream automation vendor with no unusual plant, buy a packaged product and put the difference into commissioning, which returns more at that scale.
On this page
The threshold is automation vendor variety rather than building count. Under about 10 buildings on a single mainstream automation vendor with no unusual plant, buy a packaged product and put the difference into commissioning, which returns more at that scale. Above roughly 20 buildings with mixed vendors and controller generations, price both properly: a detection core runs $95,000 to $200,000 over 14 to 22 weeks and a full operations platform runs $240,000 to $650,000 over 9 to 16 months. Most portfolios sit below the build threshold, and the tagging work is yours in either case.
When is off the shelf genuinely the right call here?
For a modest estate on one mainstream automation vendor, with no unusual plant and no internal appetite to develop rules, buying is clearly right and a build would be an expensive way to arrive at the same place. Below about 10 buildings, buy and spend the difference on commissioning, because at that scale correcting the sequences returns more than detecting faults in them.
The products worth naming are real. SkySpark has a strong analytics engine with deep roots in the Project Haystack tagging model and will do sophisticated rule work, provided somebody is committed to developing and maintaining rules in it. That clause matters: it is a platform, usually delivered through a systems integrator, and the outcome depends heavily on who is holding it. Clockworks Analytics pairs fault detection with an analyst service, which is the right shape for an organisation that wants findings delivered rather than a system to run. Switch Automation, KODE Labs and Facilio each combine data integration with dashboards and operations workflow, and they are credible where you want a packaged operating layer rather than a component.
Buy also when the honest constraint is people. A portfolio that adds detection without adding engineering capacity to act on findings has bought a longer list. Fix the capacity question first, then decide what to detect with.
When does a custom build actually pay off?
Five conditions, and you need at least two of them before the arithmetic works. First, when per point licensing becomes untenable across five years. The awkward property of a point based model is that the points which make analytics genuinely better are the same points that raise the bill, so the pricing runs against the outcome you want as you extend into plant and submetering.
Second, when a meaningful part of your estate uses controllers no product connects to cleanly. Connector coverage is excellent for mainstream systems and thinner as you go back through older generations, which is exactly where an estate assembled by acquisition hurts.
Third, when your plant runs sequences the packaged rule libraries misread. Generic rules assume a particular economiser strategy, a particular reheat configuration, a particular chiller staging logic. Where the assumption is wrong you get false positives, and false positives are fatal in this category: an engineer who investigates three findings that turn out to be design intent will stop opening the tool permanently and no dashboard quality recovers that trust.
Fourth, when fault data needs to join systems the products do not reach, particularly your maintenance system and your tariff and metering data. Fifth, when analytics is one component of a wider operations platform you already own and run.
Note what building does not mean. It does not mean writing a time series database. It means assembling proven components and putting your equipment model, your rules and your workflow on top of them.
How do they compare on the things that matter in this industry?
Compare on grounds a practitioner can verify, not on the size of a rule library.
- Connector reach into your worst building. Ask for the specific vendor and the specific controller generation at your most awkward site, not a list of logos. Each unfamiliar family runs $18,000 to $45,000 of ingestion work before a single rule is written, whoever does it.
- Rule precision against rule count. Twenty rules that are right beat two hundred that are noisy. Ask how a rule is tuned per site, how suppression windows stop a fault re firing every fifteen minutes, and whether an engineer marking a finding as design intent actually adjusts the rule.
- Per point economics across five years. Model the point count you expect to have when plant and submetering are connected, not the count you have now.
- The verification loop. Whether a closed work order triggers an automatic re check that reopens the fault if the behaviour returns. This is the feature most often missing and the one that converts a sceptical engineering team into a committed one.
- Model portability. The tagging and equipment model you accumulate over several years is the real asset. Ask what it looks like on the way out.
One thing does not belong in the comparison, because it lands on your side of the table either way. Applying a tagging standard to 40,000 points across an estate that grew by acquisition is a data project with real hours in it, and any comparison that puts it only on the build side is wrong.
What does total cost of ownership look like at your scale?
A detection core covering ingestion from two automation vendors, point normalisation and tagging across 10 to 15 representative buildings, an explicit equipment model, a rule engine with a tuned starter set and a triaged fault queue runs $95,000 to $200,000 over 14 to 22 weeks in Digital Heroes delivery experience. A full operations platform adding further vendors, tagging rollout across the estate, energy cost attribution with utility reconciliation, maintenance integration with automatic verification and portfolio reporting runs $240,000 to $650,000 over 9 to 16 months. Where sites expose live values but no historical trending, add $25,000 to $70,000 for a collection layer, because analytics cannot run on a system that does not remember.
A worked 60 building estate with roughly 40,000 points and four automation vendors lands at about $158,000 for the first release and $405,000 for the programme across roughly fourteen months. Normalisation dominates the first release, not the rule engine, which surprises most people.
Running costs are the half that gets left out of both sides. Point growth from retrofits, new controllers and new meters is $8,000 to $25,000 a year and never stops. Rule tuning is $15,000 to $40,000 a year and is not optional, because untuned rules become false positives. Time series storage and compute is $9,000 to $30,000. Connector maintenance is $6,000 to $18,000, and a silently failing connector reads as a building with no faults. Support and enhancement runs 15 to 20 percent of build cost annually.
Set either number against what the estate is losing rather than against the other. The waste in most portfolios is not dramatic failure, it is correct looking equipment running an incorrect sequence: a valve passing, a damper stuck at minimum position, a schedule override nobody removed after a weekend event in February. None of it trips an alarm, all of it looks normal on a year over year chart, and it persists for months because there is no mechanism to notice.
What does the hybrid look like, and when is it the honest answer?
Buy the platform and build the thin layer you actually need. For a large share of portfolios this is the correct answer and it is cheaper than either extreme.
The shape that works: keep SkySpark or a comparable engine doing detection, and build the operations layer around it. That layer estimates a defensible cost per fault against your tariff including demand charges, ranks the queue in currency your operations director recognises, groups related faults so one failed sensor does not generate twenty work orders, raises the work order inside the maintenance system your technicians already use with the trend evidence attached, and runs the scheduled re check after closure. Nothing in that list is analytics. All of it is the difference between a fault list and corrected equipment.
The other credible hybrid is buying the findings rather than the tool. An analyst backed service such as Clockworks suits an organisation with engineering capacity but no rule development appetite, and you can still build the workflow and cost attribution around what arrives.
The hybrid stops being honest in one situation: when the packaged engine cannot reach a meaningful share of your estate. A layer on top of coverage you do not have produces a beautiful operations workflow for two thirds of your buildings and silence from the third that was acquired.
Which should you choose, by portfolio size and stage?
Under about 10 buildings on one mainstream vendor: buy, and spend the difference on commissioning. A build here is money that should have gone into correcting sequences.
Ten to about 20 buildings, one or two vendors, some appetite to develop rules: buy the platform, and if anything is built, build only the work order loop and the verification re check. That is a small project against a licence you are keeping.
Twenty to 60 buildings with three or more automation vendors and at least one legacy estate behind a gateway: price both properly. Start with 10 to 15 representative buildings, prove faults and their cost estimates there, and fund the rollout from that result rather than buying a portfolio wide deployment on a promise. Choose the buildings your engineers already argue about, not the ones with the cleanest data.
Above 60 buildings, or any size where a packaged deployment has already stalled because thousands of faults met a team of six: build the detection core and own the equipment model. At that point the model is a portfolio asset worth years of accumulated engineering knowledge, and it should not sit inside a licence you have to keep renewing to read.
Service providers delivering analytics to clients are a separate case entirely. There the platform is part of what you sell, so the question is margin and differentiation rather than cost, and licensing somebody else's engine caps both.
When the shortlist is down to two and you need a tiebreaker, Digital Heroes writes a product requirements document before any code exists, so the scope is fixed and priced rather than discovered later at a day rate. The document is yours whichever way you go.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Flexera's 2025 State of the Cloud Report (survey of 750+ technical and executive leaders) found that 84% of respondents believe managing cloud spend is the top cloud challenge for organizations today, with cloud budgets already exceeding limits by 17%. Source: Flexera (2025) →
- Deloitte reports that modern ERP implementations aim to deliver reduced manual effort, greater transparency, a single source of truth, and increased productivity, but many organizations do not capture the full expected benefits (a significantly lower ROI) without disciplined strategy, change management, and data readiness. Source: Deloitte (2024) →
- Retailers connecting point-of-sale and loyalty data in an omnichannel strategy reported up to 15% lower cost per purchase and nearly 20% higher incremental store revenue. Source: Deloitte (2024) →
- This World Bank report argues that digital technology adoption raises SME competitiveness, productivity and resilience, while documenting that smaller firms consistently lag larger ones in digital adoption - a gap that constrains their growth and market reach. Source: World Bank (2022) →
Frequently asked questions
What does it cost to switch off SkySpark or another packaged platform later?
The licence stops and the tagging does not transfer cleanly. Your equipment model and rule set are expressed in the product's own terms, so a move means re expressing the model and rebuilding the tuning that made the rules usable, which is most of the value you accumulated.
Two things reduce that cost and both are free to ask for now. Insist on a recognised vocabulary such as Project Haystack or Brick Schema rather than a proprietary one, and get a documented export of the point mappings and equipment relationships. That turns a rebuild into a translation.
What happens if our analytics licence is repriced as we add points?
It is the most predictable cost surprise in this category, because licensing here is commonly related to point count and the points that make analytics better are the points that raise the bill. Extending into central plant and submetering, which is exactly what improves fault detection, increases the licence at the same time.
Model your renewal on the point count you expect in five years rather than today's, and add the integrator or analyst time you pay alongside the licence, because the product rarely produces value without somebody developing rules. That total is the number to compare against a build.
How long does a first release take, and what sets the schedule?
Fourteen to 22 weeks, and point normalisation dominates it rather than the rule engine. Each commissioning contractor was internally consistent even where they disagreed with every other contractor, so pattern clustering with bulk human confirmation is far faster than point by point tagging. Any plan assuming manual tagging stalls around building six.
The other schedule item is network access and information security review, which in corporate, healthcare and institutional estates commonly adds four to ten weeks of calendar without adding a line of code. Start that conversation before kickoff rather than in week six.
Is SkySpark enough on its own, or do we need to build?
SkySpark has a strong analytics engine and will do sophisticated rule work, but it is a platform whose results depend on who develops and maintains the rules, usually a systems integrator. If you have that relationship and your estate is on mainstream systems, it is enough.
It becomes limiting when per point licensing gets untenable at your scale, when part of your estate uses controllers the connectors do not reach cleanly, or when fault data needs to join systems the product does not touch. Note that the tagging and equipment modelling work is yours either way.
Why do false positives matter more here than in other software?
Because trust is spent once. An engineer who investigates three findings that turn out to be design intent will stop opening the tool permanently, and no amount of dashboard quality brings them back. Generic rule libraries cause this because they assume a sequence of operations your plant may not run.
Where a building runs standardised high performance sequences, rules can be written against a documented intent. Where it does not, which covers most existing buildings, the rules have to be written against what that specific plant is supposed to do, which means reading the sequence of operations and talking to whoever maintains it.
Can we buy the platform and build only the work order and verification layer?
Yes, and for many portfolios that is the best value available. Detection is the part packaged products do well. The part they underbuild is what happens next: cost ranked triage against your tariff, grouping so one failed sensor does not raise twenty work orders, the work order landing in the maintenance system your technicians already open, and a scheduled re check after closure.
Fund the verification half rather than trimming it. Faults reappearing weeks after a work order closes are common in our experience, and verification is what proves the tool measures outcomes rather than generating findings.
Can either option tell finance what a fault is actually costing?
Both can, and the estimate has to be built to survive scrutiny rather than to look impressive. It compares observed consumption against a reasonable counterfactual for that equipment under those conditions, priced at your actual tariff including demand charges, with the assumptions visible and reconciled at building level against metered and billed consumption.
A precise savings figure with no stated assumptions will be challenged by your finance team and it will lose, and losing that argument once costs more than the analysis was worth. Sequence cost attribution after three months of fault history, since the estimate needs to know how long a fault typically persists.
What is the cheapest credible version of a custom build?
Around $95,000 for a detection core scoped to two automation vendors and 10 to 15 representative buildings, with an existing tagging vocabulary adopted rather than invented, pattern clustering instead of manual tagging, and a deliberately small tuned rule set.
Below that, buy. Be sceptical of any developer whose first answer to normalising 40,000 points across four vendors is manual tagging, and of any pitch whose headline is the size of the rule library. Precision is cheaper than coverage and it is the only thing that keeps engineers opening the tool.
Will a custom dashboard stay fast once our data hits millions of rows?
Yes, if it aggregates before it displays; no dashboard should scan millions of raw rows on every page load. The standard techniques are pre-aggregated summary tables, incremental refresh, and caching, which keep typical page loads under 2 seconds even on datasets in the hundreds of millions of rows. Ask your vendor how the dashboard behaves at 10 times your current data volume; a good one gives a specific answer about aggregation, not just a bigger server.
Can one dashboard pull from QuickBooks, Salesforce, and Google Analytics at the same time?
Yes, and combining sources like that is the main reason to build custom instead of living inside each tool's built-in reports. The standard pattern syncs each source into one warehouse using connectors such as Fivetran or Airbyte, then joins them there, so marketing spend, pipeline, and revenue finally sit in a single view. Each additional source typically adds 1 to 2 weeks to the build, mostly for field mapping and reconciliation.
Can we migrate years of data out of our current system into new custom software?
Almost always yes, through CSV exports or the vendor's API, and migration should be scoped as its own workstream with field mapping, a dry run, and a planned cutover window rather than an afterthought. The real time sink is rarely moving the data; it is cleaning it, since years of duplicates, free-text fields, and inconsistent formats surface all at once. Pull a full export from your current vendor before committing to anything new, because some SaaS plans restrict exports on lower tiers.
How do I work out whether a custom dashboard will pay for itself?
Add up three numbers: hours of manual reporting it removes each month, license seats it replaces or avoids, and the value of one or two decisions it speeds up, like catching margin slippage a month earlier. Across Digital Heroes projects, internal dashboards typically pay back in 8 to 18 months, and customer-facing dashboards pay back faster when analytics is a paid feature or reduces churn. If the honest math does not clear payback within 2 years, buy an off-the-shelf tool instead.
How many people does it take to build a custom BI dashboard?
A typical build runs with 3 or 4 people: a data engineer for pipelines and modeling, a full-stack developer for the application and charts, a part-time designer, and a project lead. One strong freelancer can handle a single-source internal dashboard, but in our experience solo builds stall once multiple integrations, permissions, and customer access are added. Team size matters less than having one person explicitly own the data model.
If we move off Power BI or Tableau later, do we lose our historical data and reports?
Your raw data is safe because it lives in your source systems or warehouse, not inside Power BI or Tableau. What you lose is the logic layered on top: DAX measures, calculated fields, and report layouts all have to be rebuilt, and that rebuild is the real switching cost. Protect yourself now by keeping transformations in dbt or in warehouse views instead of inside the BI tool, so a future migration only replaces the screens.
How do I vet an agency or developer for a BI dashboard project?
Ask them to walk you through the data model of a past project, not a portfolio of pretty charts, because dashboard failures are almost always data modeling failures. Good answers mention specifics like star schemas, dbt, incremental refresh, and how they handled a source schema change after launch. Then ask for a fixed-scope discovery phase with a written data audit as the deliverable, so you judge their real work for a small spend before committing to the build.
We already pay for Microsoft 365. When does building custom actually beat Power BI?
Keep Power BI for internal reporting; at $14 per user per month for Pro it is hard to beat for employee-facing analytics. Custom wins in three cases: you are showing dashboards to customers, since embedded Power BI is priced on capacity and gets expensive fast, you need a fully white-labeled experience inside your own product, or your team keeps fighting the tool to support a specific workflow. Most companies we build for keep Power BI internally even after launching a custom customer-facing dashboard.
Should I embed Power BI or Tableau in my SaaS product, or build custom charts?
Embed first if you need analytics inside your product within weeks, but treat it as a bridge rather than the destination. Embedded licensing meters your customer traffic, so your analytics cost grows with your user count, and the look and feel never fully matches your product. In Digital Heroes projects, SaaS teams usually switch to custom charts built in React with a library like ECharts or Recharts once analytics becomes a selling point instead of a checkbox.
How does a custom dashboard handle compliance requirements like SOC 2, HIPAA, or GDPR?
A custom build gives you direct control over the controls auditors ask about: single sign-on, role-based access, audit logs, encryption, data residency, and deletion workflows. For HIPAA specifically, you can keep protected health information inside your own cloud account under a business associate agreement with your host instead of trusting a third-party BI vendor's handling. Expect compliance work to add 2 to 4 weeks and roughly 10 to 15 percent to the build, so raise it in the first conversation, not after design is done.
Who can build a custom business intelligence dashboards system?
Digital Heroes builds custom business intelligence dashboards systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other business intelligence dashboards companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
More from Sanya.
Frontend Engineer · Delhi · 1 post on the site
Published · Last updated .
