Why energy SaaS teams shouldn't roll their own inverter adapters: 3 years in production
First-time cost, long-term maintenance, API revision incidents, decision framework — based on three years of Zenergy Monitor production.
It was a normal Tuesday morning. Five minutes into standup, the engineering lead wiped the whiteboard.
"We just spent another three weeks integrating our fourth inverter vendor. Five to seven weeks each, on average. Counting the prior three, we've put five engineer-months into 'integration' this year alone."
"What's our product? A monitoring dashboard. What new customer-facing feature did we ship to the dashboard this month?" A "0" went up on the board.
That day we decided: this can't keep going.
Three years later, that decision became ZenovaConnect. This piece is the postmortem on the reasoning — why for energy SaaS teams, building vendor adapters from scratch is almost always the wrong call.
The real cost of first-time integration
Your engineers work eight hours a day. Subtract meetings, code reviews, and miscellaneous interrupts, and a week of pure coding is roughly 25 hours. The numbers below come from three years of Zenergy Monitor's experience across 15 vendors.
Onboarding a new vendor goes through four phases:
- Account application: business-side negotiations, NDAs or API agreements, waiting for credentials. Calendar time 1–6 weeks; engineer-hours actually invested are 1–3 days (wait time doesn't count as effort but it does delay delivery)
- Doc digestion: reading API docs, understanding auth, decoding field meaning. 1–5 days depending on doc quality
- Field mapping: mapping vendor fields onto your unified schema, handling units, timezones, sampling intervals. 3–5 days
- Error handling + testing: rate limits, retries, timeouts, unit tests, pre-launch observation. 3–5 days
Total: 4–8 weeks of engineer time per new vendor (excluding wait time).
There's a pattern. Breakdown by vendor type:
| Vendor type | Account wait | Doc digestion | Field mapping | Error handling | Engineer total |
|---|---|---|---|---|---|
| Domestic top-tier (Huawei / Sungrow / GoodWe level) | 1–2 weeks | 2–4 days | 3–5 days | 3–4 days | 4–6 weeks |
| Domestic mid-tier (Solis / Growatt level) | 1–3 weeks | 1–3 days | 3–5 days | 3 days | 5–7 weeks |
| Domestic smaller vendors | 2–4 weeks (long business cycle) | 1–2 days | 2–4 days | 2 days | 6–8 weeks |
| Overseas brands (SMA / Fronius level) | 2–6 weeks (international support) | 2–5 days (English docs) | 3–5 days | 4–5 days | 6–12 weeks |
Note: domestic smaller vendors aren't necessarily easier than top-tier. Top-tier vendors have complete docs, consistent field naming, and changelog-tracked revisions; smaller vendors often have outdated docs, require email back-and-forth to confirm field semantics, and the business cycle can drag for a month.
Long-term maintenance: the real hidden cost
First-time integration cost is relatively visible — it's a one-time investment, it shows up in a project plan.
The expensive part is long-term maintenance. It doesn't appear in a project plan. It re-occurs every month, every quarter, every vendor release.
Maintenance breaks down into four categories:
| Maintenance item | Frequency (per vendor) | Engineer-time per incident | Annualized engineer-days/vendor |
|---|---|---|---|
| API minor version upgrade | 2–4 times/year | 2–4 days | 6–12 engineer-days |
| Field semantic drift tracking | Irregular (avg. 5–8/year) | 0.5–2 days | 4–8 engineer-days |
| Credential / cert rotation | Every 6–12 months | 1–2 days | 2–3 engineer-days |
| New device model alarm code expansion | Per new model | 1 day | 3–5 engineer-days |
| Total | 15–28 engineer-days/year/vendor |
Put that on your plate: integrate 5 vendors, expect 75–140 engineer-days/year of maintenance, roughly 0.4–0.7 of a full-time engineer.
That excludes incident response. Incidents are a separate story — when they happen, they push all other priorities aside, typically requiring a response within an SLA-bound 24-hour window. Next section covers incidents.
The point here: maintenance is not "what happens after the project ships." It's "the project never ships." Every vendor is a product line you maintain forever. The more you integrate, the harder the maintenance team can keep up.
Three real incidents: API revision risk
It's not "if it changes" — it's "when." Three incidents from production, anonymized:
Incident 1: Units quietly changed
A top-tier vendor's inverter model started returning EDay (daily energy production) in kWh × 10 instead of kWh. No changelog entry.
We found out because customers were watching their plant daily-yield in the product, and one day the number 10x'd. The monitoring dashboard looked like the plants had "exploded." An engineer dug in and found the unit had changed.
Aftermath: 6 months of historical data resent (with unit conversion); customer trust repair; monitoring rules updated to verify unit (to prevent recurrence).
Engineer cost: 2 weeks + customer relationship repair.
Incident 2: Silent OAuth2 endpoint migration
A vendor a major SOE customer integrated released v3 API and silently 410'd the old OAuth2 endpoint.
We found out because the customer alert group blew up at 11pm — every connection to that vendor stopped.
Response: requested new endpoint credentials overnight, modified the auth logic in the collection pipeline, restarted all that vendor's collection jobs.
Engineer cost: 8 hours of downtime + one engineer working all night. After this, we established a monthly change-notification cadence with the vendor.
Incident 3: Overseas vendor rate limit tightened
An overseas vendor tightened the API rate limit from 1000 req/min to 100 req/min. No warning.
We found out because the historical backfill scripts were all 429-failing, blocking history replay.
Response: rewrote the collection strategy — 10x lower concurrency, incremental requests sharded, added a request queue.
Engineer cost: 3 days of focused engineering.
What these three incidents have in common: none of them is technically hard, but every one of them requires immediate response. If your team maintains 10 vendors concurrently, expect 15–20 of these "must respond now" events per year. That's the real hidden cost.
Decision framework: when to build vs buy
Internalize the cost structure, and the decision becomes:
Build it yourself when:
- You're integrating only 1–2 dedicated vendors with no plan to expand
- Your integration requirements are deeply custom (proprietary protocols, private fields, special logic) and no generic layer covers them
- Your data compliance is so strict no third party can participate in collection (note: a Self-Hosted integration layer still meets this — see next article)
Buy the integration layer when:
- Your product needs to cover 5+ vendors
- Your customers keep asking for new vendors
- Your engineers' time should go into your core product (dashboards, AI reports, dispatch optimization)
- You need SLA guarantees and ongoing maintenance commitment
Decision table:
| Your scenario | Build | Buy |
|---|---|---|
| 1–2 dedicated vendors | ✅ | |
| 5+ domestic vendors | ✅ | |
| Overseas brand coverage | ✅ (outsource overseas credential flow) | |
| Short PoC validation (<1 month) | ✅ | |
| Data must not leave the network | ✅ or Self-Hosted layer | ✅ (Self-Hosted) |
| Long-term SLA boundary clarity | ✅ (clear service line) |
Note the "data residency" row — many teams default to "must build" but a Self-Hosted integration layer is an alternative. The next article covers Cloud vs Self-Hosted.
One line
Integration work doesn't differentiate your product, but it consumes your most expensive engineering resource.
Outsourcing it to a team that does only this work, has three years of production data, and supports both Cloud and Self-Hosted deployment is the call most energy SaaS teams make by their third vendor.
We made that call. Three years later, the capability became ZenovaConnect.