If you run C&I solar projects, you have probably had this debate internally at least once: should we keep paying consultants to run our ASTM E2848 capacity tests, or should we bring it in-house?
Having talked to enough EPCs, developers, and asset managers, I can tell you there is no universal right answer. But there is a wrong way to make the decision — and that is defaulting to "how we have always done it" without actually running the numbers.
Here is a framework that cuts through the noise.
The Three Variables That Actually Matter
1. Test volume per year
This is the single biggest driver. If you are running one or two capacity tests a year, having the test run for you probably still makes sense — by a consultant, or as a managed test — because the fixed cost of building internal expertise and tooling is not worth it for occasional use.
But once you cross into three or more tests a year, the math starts to flip. At roughly $4,000 per site for external consultants, a team running five tests annually is spending $20,000 a year on something that could be standardized and brought in-house for a fraction of that cost. (Our capacity test cost guide puts current numbers on all three routes — consultant, in-house software, and managed testing.)
2. In-house technical expertise
ASTM E2848 is not trivial. It requires understanding regression modeling, data filtering criteria, weather normalization, and how to interpret a failed test rather than just reporting one. If your team has PV or project engineers who already understand system performance — even if they have never run a formal capacity test — the learning curve to bring testing in-house is manageable, especially with the right tooling.
If your team has zero engineering bandwidth for this, whoever runs the test for you — consultant or managed service — is doing real work you would otherwise have to build from scratch. That is a legitimate reason to keep outsourcing, regardless of volume.
3. Tolerance for process risk
This one gets overlooked. Custom Excel or Python-based in-house tools introduce their own risk: inconsistent methodology between engineers, version control issues, and the occasional regression error that goes unnoticed until it causes a failed audit. If you are bringing testing in-house without a standardized, repeatable process, you may be trading one risk (consultant cost and opacity) for another (internal inconsistency).
Teams that successfully bring testing in-house usually do one of two things: they invest significant time building rigorous internal documentation and QA around their spreadsheet process, or they adopt purpose-built software that enforces the standard's methodology by design.
A Simple Way to Think About It
| Low volume (1–2 tests/yr) | Moderate volume (3+ tests/yr) | |
|---|---|---|
| Low internal expertise | Have it run for you — a managed test or a consultant | Software with guided workflows, or managed tests while the team ramps up |
| Moderate-to-high internal expertise | Managed test or consultant (unless cost is a major concern) | In-house — via standardized tooling, not ad hoc spreadsheets |
The pattern: volume changes the economics, but expertise (or the right tooling to compensate for its absence) changes the risk profile. You need both favorable economics and manageable risk to justify bringing the test in-house.
What Most Teams Get Wrong
They evaluate this decision purely on cost — "consultants are expensive, let's do it ourselves" — without accounting for the process risk of ad hoc internal tooling. A failed audit or an incorrectly reported test result costs far more than the money saved by cutting out the consultant.
This is the same trap that catches teams who underestimate the real cost of Excel-based capacity testing: the hidden engineer hours, silent formula errors, and missing audit trails rarely show up in the initial cost comparison.
The teams that make this transition successfully treat it as a process change, not just a cost-cutting exercise. They ask: how do we get the cost savings of in-house testing without losing the standardization and reliability a consultant was providing?
How HelioTest Fits This Decision
The reason this decision has traditionally been binary — expensive consultant or risky spreadsheet/python scripts — is that there was nothing in between. Purpose-built software changes that, in two ways. HelioTest is built to give a team the cost profile of in-house testing with the standardization a consultant provided, by enforcing the ASTM E2848 methodology directly in the workflow. And for teams on the low-volume side of the table, we run the test ourselves on the same platform as a managed test — for less than a traditional consultant engagement, with every filtering and regression decision left inspectable rather than buried in a PDF.
That matters most for the two variables where in-house teams get into trouble. On expertise, guided workflows walk an engineer through regression setup, data filtering, and reporting-condition calculation, so a team that understands PV performance but has never run a formal capacity test does not have to build that knowledge from scratch. On process risk, the methodology is applied the same way on every test and every engineer, and each run produces an audit-ready report — no version-control drift, no per-engineer spreadsheet variance.
It also handles the cases that make ad hoc tooling brittle in the first place, such as multiple array orientations, bifacial modules, and GHI-only sensor setups, natively — so bringing testing in-house does not mean writing custom scripts for every non-standard site.
If you are on the fence about volume, one more point: because both routes run on the same platform, the choice is not permanent. A managed test leaves you with a live project in HelioTest that your engineers can open and inspect — a worked example of your own site — and when volume grows, the next test can be one they run themselves. A consultant engagement leaves you with a PDF and nothing to build on. If you are not sure which side of the table you are on this year, a 30-minute scoping call is the fastest way to find out — bring your expected test volume and your contract's test exhibit.
Key Takeaways
Whether to keep using a consultant or bring ASTM E2848 capacity testing in-house comes down to three variables: your annual test volume, your in-house technical expertise, and your tolerance for process risk. Volume changes the economics; expertise and tooling change the risk profile. You need both in your favor to justify the move.
The teams that get this right do not treat it as a simple cost-cutting exercise. They treat it as a process change — and they look for a way to capture the savings of in-house testing without losing the standardization and reliability a consultant provided.
If you are weighing this decision for your own team, HelioTest offers a free tier so you can try the in-house workflow on your own data before committing to a change. And if this year's volume does not justify bringing testing in-house at all, a managed test gets the one-off done without a consultant engagement — and without closing the door on running the next one yourself.
Peter is an engineer with a PhD in renewable energy management and over a decade of experience in software development for renewable energy applications. He built HelioTest to replace the fragile spreadsheet workflows he encountered across dozens of ASTM E2848 capacity tests.
