Commercial Solar Installer Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does the generic project tool scope failure happen so often?

The biggest scope failure in commercial solar is treating the work as generic project management with a few custom fields. It is an easy mistake because the shape looks familiar: tasks, dates, owners, documents. So a team configures Smartsheet or monday.com, or a developer proposes a project system with a flexible schema, and everyone is pleased for about a quarter.

It fails because the domain objects are not tasks. A site survey is a structured record with roof type and membrane thickness, azimuth and tilt per plane, main breaker and busbar ratings, conduit path and geotagged photographs of the point of interconnection. An authority having jurisdiction is a requirement template with its own plan set contents and fees. A utility interconnection is a sequence of milestones each carrying a clock. None of those are expressible as a row with columns, and pasting them into cells is the symptom that the tool is dictating your process.

The consequence is not cosmetic. When survey conditions live in a photograph rather than a field, the designer never sees the panel constraint and specifies a system the service cannot accept without an upgrade, and the crew finds out on the roof. When jurisdiction requirements live in a person's memory, a plan set goes in incomplete and you lose two weeks.

Insist that a prospective developer whiteboards the data model from survey to Permission to Operate before quoting. If they show a generic project with custom fields, you are buying the tool you already have.

What goes wrong when you migrate from spreadsheets and shared drives?

Three data sets and only one of them migrates cleanly. Active projects are the priority and the hardest, because every one is mid flight with a permit somewhere, an application somewhere else and a crew booked. The workable pattern is parallel running: the new system goes live for new jobs while in flight projects finish where they are, then open projects are imported once the team trusts the tool. Trying to move a live interconnection queue mid stream is how a deadline gets missed during the migration itself.

Survey and photograph archives are the second problem. Years of roof photographs sit in a drive organised by job name, with no reliable link to the plane, the elevation or the equipment they show, and orientation data that is inconsistent. There is no automated way to recover that structure, so the honest decision is to leave the archive addressable in place and start capturing structured surveys from launch.

Closed historical projects are the third and here restraint pays. Import them as flat records for reporting rather than modelling them fully. The value in old jobs is a handful of numbers, cycle times by jurisdiction, actual versus estimated labour, equipment used at a site you may service later, not a complete reconstruction.

The thing worth doing carefully is the survey and permit schema itself, because everything downstream reads from it. Get that right before the first import and the rest is manageable.

Why do the design, accounting and monitoring integrations break after launch?

Four connections carry a commercial solar build. The design tool is the first: Aurora Solar or OpenSolar produces the array layout and the bill of materials, and the failure is version drift. A design gets revised after procurement started, the material list moves, and nobody links the revision to the purchase orders already raised. Decide explicitly which design version is authoritative for procurement and lock it, with a visible re approval step when it changes.

Accounting is the second, and it breaks at the boundary between a project and a job cost. Purchase orders raised against a project need to reconcile to the ledger by job, and if that mapping is not agreed with your controller before build, month end becomes an argument and your project margin reports are never trusted.

The customer relationship system is the third, and the failure is ownership of the record. Sales owns the opportunity, operations owns the project, and if both can write the same fields you will get two versions of a site address, which then produces a measurement report ordered against the wrong roof.

Monitoring is the fourth and it fails quietly, which is worse. Provisioning a site in a monitoring platform is a step that can appear done while alerts route nowhere, so a string outage runs for weeks. Make confirmed alert delivery, not portal creation, the condition for marking a system energised.

What happens when tax credit and wage evidence is not covered?

The Investment Tax Credit is usually the largest single financial line on a commercial project, and the bonus rates depend on prevailing wage and apprenticeship records and on domestic content documentation. When certified payroll hours and apprentice ratios are reconstructed in a spreadsheet at tax time, the credit basis is difficult to defend and the multiplier is exposed.

The failure is one of timing rather than diligence. The evidence has to be created at the point of work, by people on a roof, and nothing in a design tool or an accounting package asks them for it. So it gets assembled months later from timesheets that were never structured for the purpose, by an accountant who was not there.

What covering it looks like: certified payroll hours captured per worker per day against the project, apprentice ratios computed as work happens rather than at the end, domestic content attributes attached to the bill of materials items when they are procured, and the placed in service date recorded with its supporting documents. The credit package then assembles from records the crew already entered.

The same discipline serves the draw schedule. Milestone financing releases money at permit, mechanical completion and Permission to Operate, and when those gates are tied to real system states rather than to a coordinator emailing a lender, the draw request goes out the day the gate is met instead of the week someone notices.

Should you build custom or configure what you already own?

If you are a single region installer under roughly thirty commercial projects a year with a standard workflow, and Scoop Solar or Sitetracker matches how you run, do not build. The tool fits, and you would spend six figures recreating software that already exists. Procore is likewise strong for general construction and is a reasonable answer if your work is closer to construction management than to a solar specific pipeline.

Before building, be honest about whether the problem is the tool or the process. Interconnection windows get missed most often because notices arrive in personal inboxes and nobody owns the queue, and creating a shared mailbox with a named owner and a weekly review fixes a meaningful share of that for nothing. Do that first and measure for a quarter. If deadlines still slip after the ownership is clear, the problem is structural and worth building for.

The build case is concrete. You run multiple locations. Spreadsheet reconciliation has become somebody's actual job. Your milestone financing or tax credit documentation does not fit any template. You are integrating across five or more systems by hand. And the clearest signal of all, you are pasting solar specific data into generic cells to force a tool to fit. When the workaround costs more than the software would, build.

How do hidden costs get into the quote?

The jurisdiction library is the largest and it is not a build cost, it is a maintenance cost. Each authority having jurisdiction has its own plan set requirements and fees, each utility its own interconnection milestones, and all of them change. Somebody in your organisation has to own keeping that library current, and if nobody does it produces confident wrong guidance within a year. Price the ownership, not just the initial data entry.

Portal automation is the second and it deserves a deliberate decision. Automating status retrieval from utility portals that have no interface is fragile work that breaks whenever the portal changes, and manual status entry with a good reminder system is frequently the better value. Ask for both to be priced so you can choose rather than assume.

Offline survey capability is the third, because commercial roofs and rural sites lose signal and a survey that cannot be completed is a second truck roll. Multi tenancy is the fourth, and it should only be in scope if you genuinely plan to run acquired regional installers on the same platform.

Fifth is crew adoption time. Structured surveys take longer on site than a photograph and a note, and that trade is worth it, but it needs to be explained to the people doing it rather than imposed.

What separates a build that works from one that fails here?

The builds that work make the survey record the spine of the project. Design pulls from it, the permit packet pulls from it, procurement pulls from it and the install crew opens the same record. One measurement, captured once, visible to everyone downstream. When that holds, the change orders caused by a panel constraint nobody saw simply stop happening, and that alone is usually the clearest return in the first year.

They put clocks on the things that expire. Interconnection response windows, permit expiry, equipment lead times and financing milestone dates all need a countdown and an owner, with alerts that fire before the window closes rather than a status field that says what somebody last typed. Deadline misses in this business are almost never decisions, they are omissions.

They schedule backwards from material. Inverters, transformers and switchgear have long and volatile lead times, and a crew that mobilises to a site where the switchgear is six weeks out is a cost you pay twice. Pull the bill of materials from the approved design, carry a lead time per item, and reserve crew dates against material arrival rather than against optimism.

And they leave you owning the platform. Source code, database schema and deployment in your own organisation from day one, with no per seat licence back to the developer, agreed before any code is written. If a vendor keeps the code and rents it back, you have bought a subscription rather than a build, and you will discover the difference the first time you need something changed quickly.