A solar software stack should operate one company, not create separate companies inside every department.

Sales, design, operations, field teams, finance, HR, service, and management should not each maintain a different version of the same customer or project. A complete solar ERP should connect the business from lead capture through cash collection, PTO, warranty, and service. Specialist tools can still add depth, but they should extend the ERP rather than become separate systems of record.

What is a solar installer software stack?

A solar installer software stack is the complete set of capabilities a solar company uses to run the business. That includes lead generation, CRM, site surveys, design workflow, proposals, contracts, project management, engineering, permitting, interconnection, procurement, inventory, scheduling, field operations, HR, payroll, accounting, customer communication, service, warranty, analytics, and administration. The word stack does not mean the company must buy a different application for every department. It simply describes everything the business needs to operate. The strongest structure is one central solar ERP that owns the customer, project, employee, material, operational, service, and financial records, with specialist providers connected only where they offer a deeper technical service.

Why do solar companies end up with disconnected software?

Most installers do not intentionally design a software architecture. The stack grows one problem at a time. Sales adopts a CRM because lead follow-up is inconsistent. Design uses a specialist platform because proposals need faster turnaround. Operations creates a spreadsheet because project statuses are unclear. Field teams rely on chat because the office system is slow on mobile. Finance maintains a separate process because invoices, payments, and project costs are not connected. Each decision can make sense locally, but the company eventually pays for the gaps between those decisions. Those gaps appear as duplicate entry, status meetings, missing documents, incorrect equipment orders, delayed invoices, payroll corrections, outdated drawings, and uncertainty over who owns the next action.

The U.S. Department of Energy classifies design, permitting, installation, interconnection, financing, customer acquisition, supply-chain activity, inventory control, and overhead as solar soft costs. These are cross-department workflows. When each department uses a different system, the company adds administrative work exactly where margins are already under pressure. The real cost is not only software subscriptions. It is the labor spent reconciling status, the cash delayed by slow billing, the material ordered from outdated information, and the management time required to rebuild a reliable view of the company.

What should remain inside the central solar ERP?

Core business ownership should remain inside the ERP. The lead, customer, property, system, contract, project, employee, material, vendor, invoice, payment, service, and warranty records should not be recreated in several places. A complete ERP should control the full business lifecycle, even when a specialist tool performs one technical part of it. The approved design, sold equipment, project stage, permit status, purchase commitment, inventory allocation, crew assignment, labor time, billing milestone, project cost, and customer communication should all remain connected.

This matters because solar work is not a series of independent departments. A design revision can change the permit packet, equipment order, installation plan, project budget, margin, and customer expectation. A material shortage can change the schedule, crew assignment, cash requirement, and billing date. A failed inspection can create rework, labor cost, a permit follow-up, a customer update, and a delayed payment. When those effects live inside one ERP, the company can see the full impact instead of discovering it later through meetings and spreadsheets.

How should CRM, proposals, and contracts work inside the ERP?

CRM is not an optional system that sits outside the business. It is the beginning of the project lifecycle. The ERP should manage lead capture, duplicate detection, qualification, utility and territory data, appointments, follow-ups, opportunities, sales activities, proposal status, objections, forecasting, lost reasons, and sales ownership. When the customer signs, the sold scope should move directly into project delivery without another customer record, another document folder, or another manual handoff. The proposal and contract should preserve what was actually sold, including system size, equipment, financing assumptions, incentives, adders, exclusions, timeline commitments, customer responsibilities, and approval history.

Operations should not need to interpret sales notes or rebuild the scope from a PDF. A controlled sales-to-project handoff should confirm that the contract, design inputs, site information, documents, payment terms, and customer requirements are complete before engineering, permitting, procurement, and scheduling begin. Sales is not separate from operations. It is the beginning of operations, and the quality of that handoff shapes every stage that follows.

How should site survey, design, and engineering connect?

The site survey should create structured project information, not just a folder of photos. The ERP should connect survey scheduling, address validation, utility details, roof and electrical observations, measurements, photos, GPS data, customer access notes, equipment location, shading concerns, and completeness checks. Missing survey information should block the next step instead of becoming a design question days later. The design workflow should manage requests, assignments, system configuration, equipment selection, production assumptions, revisions, customer approvals, engineering reviews, and approved-for-construction packages.

A specialist design engine may still provide aerial imagery, CAD, engineering calculations, or production modeling. That tool can perform the technical task, but the ERP should retain the request, version, approval status, equipment, proposal impact, permit impact, procurement impact, and project history. Engineering revisions are especially important. The team should know which plan set is current, why it changed, who approved it, and which downstream tasks are affected. Field teams should never receive an outdated drawing because a new version was saved in another folder.

Why must permitting and interconnection stay connected to the project?

Permitting and interconnection are not isolated administrative tasks. They affect design, scheduling, customer communication, procurement, field readiness, billing, and cash. A permit workflow should track the AHJ, requirements, forms, fees, submission package, responsible owner, review dates, correction comments, resubmissions, approval, inspection, and days in stage. The project team should be able to see exactly why a permit is waiting and what action is due next. Interconnection should continue from utility identification through application, study, agreement, inspection, meter activity, energization, and PTO.

Berkeley Lab reported that more than 2,060 GW of generation and storage were seeking U.S. interconnection at the end of 2025, across roughly 8,200 projects. That market-scale queue is different from a residential installer's individual workflow, but it shows why interconnection visibility matters. SolarAPP+ also demonstrates the value of structured permitting. NREL reported that participating installers submitted 18,906 permits through SolarAPP+ in 2023 and that typical SolarAPP+ projects were permitted and inspected 14.5 business days sooner than projects using traditional processes. These are not Solar1 performance claims. They show why accurate data, standardized workflows, and fewer manual handoffs matter.

How should procurement and inventory support installation readiness?

Procurement should begin with approved project demand. The ERP should connect the approved bill of materials to supplier quotations, purchase requests, approvals, purchase orders, committed cost, delivery dates, partial deliveries, substitutions, and goods received. Buyers should be able to see which projects depend on a late item and which purchase commitments are putting pressure on cash. Inventory should track warehouses, project allocations, transfers, serial numbers, batches, material issuance, site delivery, returns, damaged items, warranty data, and available stock.

The purpose is not only warehouse accuracy. Inventory must affect the project schedule. A project should not appear installation-ready when the approved material is unavailable, assigned to another job, damaged, or still in transit. The readiness decision should combine design approval, permit status, interconnection requirements, material availability, customer readiness, crew capacity, vehicle availability, and site conditions. When these inputs live in separate systems, the schedule becomes optimistic. When they are connected, operations can distinguish a date on the calendar from a project that is genuinely ready to install.

What should field operations return to the ERP?

Field operations should be a direct extension of the project record. Crews should receive the site address, customer instructions, approved scope, latest drawings, equipment list, material status, safety requirements, checklist, required photos, known risks, and inspection requirements. The field team should not need to search chat threads or call the office to confirm which document is current. They should return arrival and departure times, man-hours, installed quantities, material used, progress photos, site conditions, shortages, damage, scope changes, safety incidents, punch-list items, completion status, and customer acknowledgement.

Those updates should immediately affect the project stage, labor cost, inventory, inspection workflow, billing milestones, and management reporting. A mobile field application is useful only when the information it captures changes the rest of the business. Field work should not disappear into a gallery of photos and completed tasks. It should update the operational and financial state of the project.

Why should HR, payroll, and fleet be connected to projects?

Employees are not only HR records. They are also the people selling, surveying, designing, permitting, procuring, installing, inspecting, supporting, and servicing projects. The ERP should connect employee records, roles, skills, certifications, attendance, leave, shifts, crew assignments, timesheets, expenses, payroll, overtime, training, and safety records to project activity.

Without that connection, operations knows who worked on the project, HR knows what the employee was paid, and finance still cannot determine the real labor cost. Project man-hours and payroll must be coordinated carefully so labor is not missed or double counted. Fleet information should also connect to field execution, including vehicle assignments, availability, maintenance, fuel, incidents, and trip costs.

Why should accounting and finance be part of the same ERP?

A complete ERP should not stop at sending an invoice-ready notification to an unrelated financial system. It should connect customer deposits, progress billing, invoices, accounts receivable, collections, supplier invoices, accounts payable, expenses, reimbursements, purchase commitments, bank activity, project budgets, actual cost, committed cost, cost to complete, forecast margin, cash flow, and financial reporting.

The accounting record should understand the project, and the project should understand its financial result. When procurement creates a purchase order, the project should see the commitment before the supplier invoice arrives. When field work completes a billing milestone, finance should know what can be invoiced. When labor or material usage changes, the margin forecast should update. When a customer payment is late, project and account teams should see the effect.

External banking, payment, tax, or accountant workflows may still require integrations and exports. That does not mean finance should operate with a separate version of the customer or project. The ERP should remain the connected source of operational and financial truth.

What happens after installation and PTO?

The software stack should not end when the installation is marked complete. The same system should continue through final inspection, interconnection, PTO, final billing, customer closeout, document delivery, asset registration, equipment warranty, workmanship warranty, service requests, technician visits, replacement parts, preventive maintenance, and O&M.

Service teams should be able to see what was sold, designed, installed, invoiced, replaced, and previously serviced. They should know the equipment serial numbers, warranty terms, prior field photos, customer communication, and payment history. This is where the value of a lifecycle ERP becomes obvious. The customer relationship continues long after the original project team moves on.

Where do specialist external tools still fit?

A complete ERP does not mean every specialist calculation or external service must be rebuilt internally. Advanced solar modeling, aerial imagery, CAD, engineering analysis, lending, payment processing, banking, communications, telematics, utility data, tax services, and equipment monitoring may still come from dedicated providers. The question is not whether the integration exists. The question is who owns the business record after the specialist task is complete.

For example, a design platform may calculate production. The ERP should still control the design request, approved version, selected equipment, proposal impact, engineering review, permit impact, purchase demand, and project handoff. A payment gateway may process a transaction, but the ERP should still own the invoice, customer balance, project milestone, and collection history. A telematics provider may report vehicle location, but the ERP should still connect the vehicle to the crew, work order, cost, and maintenance schedule.

What does a connected lead-to-service workflow look like?

A connected workflow begins when a lead enters the CRM and is validated, qualified, assigned, and scheduled. Survey information, utility data, site evidence, and customer requirements are captured against the same record. Design, equipment, production assumptions, pricing, proposal, approvals, and contract remain linked. The sold project then passes a readiness check before engineering, permitting, interconnection, procurement, and scheduling begin.

Approved materials are purchased, received, allocated, and checked before installation. Crews receive the current work package and return time, photos, material usage, progress, and issues. Inspection, corrections, interconnection, PTO, invoicing, collections, closeout, warranty, and service continue on the same lifecycle record. At every stage, the company should know who owns the next action, what is blocking progress, what has changed, and how that change affects schedule, cost, cash, margin, and the customer.

How much can a disconnected stack cost?

Consider an illustrative example. Six team leads each spend 30 minutes per day checking spreadsheets, reconciling statuses, requesting updates, or rebuilding reports. That equals 15 hours per week. At an illustrative loaded labor cost of $45 per hour, the administrative burden is $675 per week, or $33,750 across 50 working weeks.

This is not an industry benchmark or a guaranteed saving. It excludes delayed invoices, permit follow-ups, idle crews, incorrect purchasing, payroll corrections, material loss, duplicate customer communication, rework, and margin problems discovered after completion. The purpose of the example is to show how apparently small coordination tasks become expensive when repeated across several managers and hundreds of projects.

What are the warning signs that the stack is broken?

The clearest warning signs are practical. The same project has different statuses in different systems. Teams keep their own project lists. Design changes move through chat. Crews receive outdated documents. Finance asks operations what can be invoiced. Payroll does not connect to project labor. Inventory does not affect installation readiness. Customer updates are recreated manually. Management reporting requires several exports and hours of reconciliation.

Another warning sign is when employees continue updating the old spreadsheet just in case. That usually means the company has not made a clear system-of-record decision or the chosen platform does not cover the workflow deeply enough to earn trust. A system cannot become the operating core of the business while essential truth still lives in personal files, chat histories, and backup trackers.

What should buyers demand from solar software?

Do not evaluate a complete solar ERP through feature lists alone. Ask the vendor to demonstrate one real project moving across lead capture, survey, design, proposal, contract, project handoff, engineering, permitting, interconnection, procurement, inventory, scheduling, field work, employee time, payroll, accounting, PTO, service, and management reporting.

Then introduce real exceptions. Change the design. Add a permit correction. Delay a material delivery. Reassign the crew. Record a failed inspection. Change the customer scope. Miss a payment. The system should show who owns the next action, what changed, which departments are affected, and how the change reaches cost, schedule, billing, margin, and customer communication.

Buyers should also ask what is genuinely available today, what is in development, what is in pilot, and what is only planned. A broad roadmap can be useful, but it should not be confused with production readiness. The safest evaluation is to test the exact workflows the company needs now and confirm how the platform will expand over time.

How is Solar1 approaching the complete software stack?

Solar1 is being built as a complete solar-specific ERP for installation companies and EPCs. Its product direction connects executive control, CRM, surveys, design workflow, proposals, projects, engineering, permitting, interconnection, procurement, inventory, field operations, HR, payroll, fleet, accounting, customer portals, service, warranty, analytics, permissions, integrations, and platform administration.

The goal is not to place Solar1 between several core systems. The goal is to make Solar1 the connected operating system for the entire solar company, while specialist providers plug in where they add genuine technical depth. Customer, project, employee, material, operational, service, and financial records should remain connected from lead through cash, PTO, warranty, and service.

Because Solar1 is still under development, each capability should be evaluated according to its actual status. Buyers should confirm what is currently available, what is being implemented, what is being piloted, and what remains on the roadmap. The complete ERP vision should guide the architecture without turning planned scope into an unsupported availability claim.

What should a solar company do next?

Map one real project from lead to service. Mark every place information is retyped, every status that must be confirmed manually, every spreadsheet that acts as a backup, every document that can become outdated, and every delay that affects cash. Then decide which records and workflows must belong to one central ERP and which external services are genuinely specialist.

The right solar software stack is not the one with the most applications. It is the one that gives every team a reliable view of the same business. When sales, design, operations, field teams, HR, finance, and service work from one connected lifecycle, the company can grow without multiplying the confusion behind every project.