Should we build our own solar monitoring platform?

Only if you can answer yes, without straining, to at least three of five questions: is your scale large enough to amortise a permanent team, are your needs genuinely unusual, does data sovereignty require it, do you have retainable domain expertise, and is this capability strategically core. If your only strong yes is 'we have the data and the engineers', that is instinct rather than analysis, and buying — or buying then reassessing once you know your real requirements — is almost always the better path. Building is a permanent team, not a project.

What does an in-house energy analytics team cost?

Far more than the initial build estimate, which captures only the effort to reach a first version. The real, ongoing cost includes permanent salaries for a team that never disbands, scarce and expensive domain experts, continuous data engineering as OEM formats change, infrastructure and its operation, and the cost of the analytics being wrong during the years they take to mature — which on a live portfolio shows up as undetected losses. This fully-loaded multi-year figure, divided by your portfolio's megawatts, is the number to compare against a platform subscription.

When does buying stop making sense?

Buying stops making sense when several conditions align: your portfolio is large enough that a permanent team costs less per MW than any platform, you have a genuinely unusual requirement no vendor serves, data sovereignty forbids external hosting, and you have stable in-house domain expertise. When most of those hold, building — or self-hosted deployment — becomes defensible. For the majority of operators, whose needs resemble other operators' needs and whose scale does not amortise a fixed team, buying continues to make sense.

Can you start with buy and move to build?

Yes, and it is often the wisest path. Starting on a platform delivers value immediately and, just as importantly, teaches you what your real requirements are — which many operators discover are narrower than they assumed. After time on a platform you can re-evaluate with precise knowledge and adequate scale, either confirming that buying serves you or isolating a specific, genuinely proprietary gap worth building for. Buy-then-reassess avoids committing to a multi-year build before you know exactly what you need.

Build vs Buy: When an In-House Analytics Team Actually Makes Sense

Ellume Engineering — Engineering, Ellume

Building your own renewable analytics platform makes sense in a narrow set of cases: when your portfolio is large enough to amortise a permanent data team, when your needs are genuinely unusual, or when data cannot leave your control for policy reasons. For most operators, the true cost of building — not the software, but the team to run it for years — outweighs the benefit. This is a decision rule, not a sales argument, and the honest answer is sometimes build.

At some point most operators of any scale ask the question: should we just build this ourselves? It is a fair question, and it deserves a fair answer rather than a vendor's reflexive 'buy'. Sometimes building genuinely wins. The instinct to build is understandable. You have the data. You have engineers. The analytics do not look like magic — expected versus actual, some anomaly detection, a dashboard. How hard can it be to do in-house what a vendor charges for? The honest response is that the software is the easy part and the trap. What is hard, and what decides the question, is everything that surrounds the software: the years of maintenance, the domain expertise, the data engineering, and the opportunity cost of the people doing it.

Nobody regrets the analytics platform they built. They regret the three engineers they could not redeploy for the next five years.

The five questions that decide it

Strip away the emotion and the build-versus-buy decision comes down to five questions. Answer them honestly and the decision usually makes itself.

1.Is your scale large enough to amortise a permanent team? A build is not a project with an end date; it is a permanent team. Divide the fully-loaded annual cost of that team by your portfolio's megawatts. If the per-MW cost is comfortably below what a platform would charge, scale may justify building. For most portfolios it is not, because the team cost is fixed while the vendor cost scales with you.
2.Are your needs genuinely unusual? Buying makes sense when your requirements resemble other operators' requirements — which, for most monitoring and diagnostics, they do. Building makes sense when you do something genuinely idiosyncratic that no platform serves. Be ruthlessly honest here: 'our fleet is unique' is felt by almost everyone and true for almost no one.
3.Can your data leave your control? For some operators — certain utilities, certain jurisdictions — operational data cannot be sent to a vendor cloud as a matter of policy, not preference. Where that constraint is real and binding, it can force a build or a self-hosted arrangement regardless of the economics. This is one of the few genuinely decisive factors.
4.Do you have, and will you keep, the domain expertise? The software can be written by good generalist engineers. The analytics that make it worth anything require people who understand solar physics, wind aerodynamics, power systems and the failure modes of the equipment. Hiring them is hard; retaining them against the pull of companies that do only this is harder.
5.What is the opportunity cost of the people? Every engineer building internal analytics is an engineer not doing something else. For a developer or operator whose edge is in origination, construction or asset management, a permanent data-platform team is a distraction from the core business dressed up as capability.

When building genuinely wins

A fair analysis has to name the cases where build is correct, because they exist. Building wins when several of these align: a portfolio large enough that a permanent team costs less per MW than any platform; a genuinely unusual technical requirement no vendor serves; a hard data-sovereignty constraint; deep in-house domain expertise that is stable and retainable; and a strategic decision that this capability is core rather than supporting. A very large operator with an unusual fleet, a policy barrier to external data, and an existing world-class data team may well be right to build. The failure mode is not choosing build when these align. It is choosing build when only the instinct is present — the data, the engineers, the 'how hard can it be' — without the scale, the retention, or the honest reckoning with a five-year commitment.

The true cost of an in-house data team

The number that sinks most build cases is the one that never makes it into the initial business case: the fully-loaded, multi-year cost of the team, not the project. A build proposal usually estimates the effort to reach a first working version. That is the smallest cost in the lifecycle. The real cost includes: the ongoing salaries of a team that never disbands, because a platform in production needs continuous maintenance; the domain experts required to make the analytics correct, who are scarce and expensive; the data engineering to keep ingestion working as OEMs change formats and firmware; the infrastructure and its operation; and the cost of the analytics being wrong during the years it takes to mature, which on a real portfolio is measured in undetected losses. Against that, a platform's subscription is a known, bounded number that someone else bears the maintenance risk on.

Hybrid approaches

The choice is not always binary. Several hybrid patterns capture much of the value of building without the full cost.

•Buy the platform, build the edge. Use a vendor platform for the commodity layers — ingestion, storage, standard diagnostics — and build only the genuinely proprietary analysis on top, where your edge actually is. This confines the build to the part that is truly unique.
•Buy now, build later. Start with a platform to get value immediately, and re-evaluate building once you know precisely what you need and have the scale to justify it. Many operators who were sure they should build discover, after a year on a platform, that their real requirements were narrower than they assumed.
•Self-hosted deployment of a vendor platform. Where data sovereignty is the binding constraint, some vendors offer deployment inside your own environment — which resolves the policy barrier without forcing you to build and maintain the platform yourself.

A decision rule the reader can apply

Here is a rule you can apply today. Build only if you can answer yes to at least three of the five questions above — scale, unusual needs, data sovereignty, retainable expertise, core-strategic — and yes without straining. If you are answering yes only to 'we have the data and the engineers', that is the instinct talking, not the analysis, and the honest answer is buy, or buy-then-reassess. If you answer yes to data sovereignty alone, look at self-hosted deployment before committing to a full build.

What changes the answer over three years

The decision is not static. Three things move it over time. Scale: as a portfolio grows, the per-MW economics of a permanent team improve, so a build that was wrong at 200 MW may be right at 2 GW. Maturity of your requirements: after time on a platform, you understand your genuine needs precisely, which either reveals that a platform serves them (buy was right) or isolates a real gap worth building for. And the market: the platform landscape consolidates and evolves, so the buy option available in three years is not the one available today. A sensible operator revisits the decision as these change rather than treating an early choice as permanent.

Frequently asked questions

Should we build our own solar monitoring platform?: Only if you can answer yes, without straining, to at least three of five questions: is your scale large enough to amortise a permanent team, are your needs genuinely unusual, does data sovereignty require it, do you have retainable domain expertise, and is this capability strategically core. If your only strong yes is 'we have the data and the engineers', that is instinct rather than analysis, and buying — or buying then reassessing once you know your real requirements — is almost always the better path. Building is a permanent team, not a project.
What does an in-house energy analytics team cost?: Far more than the initial build estimate, which captures only the effort to reach a first version. The real, ongoing cost includes permanent salaries for a team that never disbands, scarce and expensive domain experts, continuous data engineering as OEM formats change, infrastructure and its operation, and the cost of the analytics being wrong during the years they take to mature — which on a live portfolio shows up as undetected losses. This fully-loaded multi-year figure, divided by your portfolio's megawatts, is the number to compare against a platform subscription.
When does buying stop making sense?: Buying stops making sense when several conditions align: your portfolio is large enough that a permanent team costs less per MW than any platform, you have a genuinely unusual requirement no vendor serves, data sovereignty forbids external hosting, and you have stable in-house domain expertise. When most of those hold, building — or self-hosted deployment — becomes defensible. For the majority of operators, whose needs resemble other operators' needs and whose scale does not amortise a fixed team, buying continues to make sense.
Can you start with buy and move to build?: Yes, and it is often the wisest path. Starting on a platform delivers value immediately and, just as importantly, teaches you what your real requirements are — which many operators discover are narrower than they assumed. After time on a platform you can re-evaluate with precise knowledge and adequate scale, either confirming that buying serves you or isolating a specific, genuinely proprietary gap worth building for. Buy-then-reassess avoids committing to a multi-year build before you know exactly what you need.