How to Choose Solar Design Software: Tests, Costs and Handoffs

Answer: Choose solar design software by defining the projects and deliverables your team must handle, then testing those requirements on representative projects. Compare inspectable geometry, production assumptions, electrical checks, proposal revisions, data ownership and total operating cost. Treat essential requirements as pass-or-fail gates before scoring conveniences. A polished demo, an hourly model or a P90 label alone does not establish suitability.

Before comparing tools, write down what the team must deliver and who will approve it. A sales proposal, an installer’s layout, an electrical design and an independently reviewed production assessment are different outputs. Software selection starts by identifying which of those responsibilities the proposed workflow must support.

SurgePV publishes this evaluation guide and sells solar software. Official documentation was checked on September 30, 2026. The checklist and demo timings are editorial suggestions; the numerical examples are hypothetical. This is a procurement method, not a ranked product list or a firsthand comparison trial.

Define the Project and Deliverable Requirements

Prepare a short requirements sheet before requesting demonstrations:

Avoid defining an idealized platform that contains every imaginable feature. A team outsourcing final electrical design may need a reliable handoff more than an in-house drawing engine. A consultant delivering energy assessments may need inspectable assumptions and specialist reporting more than a homeowner proposal builder.

Residential and commercial work do not divide neatly into speed versus accuracy. Both require useful input evidence and a reviewable result. More complex geometry, tariffs, storage, responsibilities or financing can change the evaluation regardless of nominal project size.

Ten Checks to Run on Representative Projects

Use projects you are permitted to share: one routine job, one awkward geometry or shading case, and a relevant commercial or storage case if those are in your pipeline. Define what each test must show before the vendor begins. Keep unknown results marked unknown rather than treating a sales claim as a pass.

1. Site Geometry and Layout

Ask the operator to show roof planes, tilt, azimuth, dimensions, obstructions and the information source. Change a roof edge or keep-out area and inspect which dimensions and module counts change. Record imagery date and any measurements requiring site verification.

A realistic render is not proof of surveyed accuracy, structural suitability or permit approval. If automated placement is used, check how the operator corrects an error and identifies the rule or assumption behind a restriction.

Test output: A layout with dimensions, inputs, unresolved survey items and a named review step. Use the site-survey guide to prepare the input register.

2. Shading Method and Electrical Effects

Add a nearby obstruction and inspect how the shading result changes with geometry, orientation and time. Ask whether the output represents a shaded-area fraction, irradiance loss, electrical mismatch loss or modeled energy loss. These quantities are related but not interchangeable.

PVsyst’s published shading documentation distinguishes distant horizon shading from near shading and separates irradiance losses from electrical effects. Its electrical treatments include a strings-based estimate and a more detailed module-layout calculation. This illustrates why a software demonstration needs to show the calculation method, not just a shadow picture.

Test output: The assumptions, method and affected outputs. An annual derate can be a declared screening approximation; do not present it as a detailed electrical shading calculation. The shading-analysis workflow provides related evaluation context.

3. Equipment and Electrical Checks

Select the exact module and inverter models you would procure. Inspect datasheet source, version, units and editable parameters. Change the inverter and verify what happens to voltage, current, MPPT, stringing and any equipment-compatibility warnings.

Ask which checks the software performs and which remain with a qualified designer. A matching brand name or populated component library does not prove every proposed combination is approved. Manually entered equipment data also require a documented verification process.

Test output: A traceable equipment selection, the electrical limits checked and the exceptions requiring review. See the inverter-sizing guide for the distinct design questions.

4. Production Model and Energy Boundary

Inspect weather source, period, coordinates, model version, orientations, capacity basis, losses and output boundary. Ask for an export that lets a reviewer reproduce or explain the estimate. Check whether the result is DC energy, inverter AC output or energy delivered at the stated meter.

The PVWatts V8 API documentation distinguishes monthly and hourly outputs and reports units: annual and monthly AC energy are in kWh, while hourly AC outputs are in watts. The same documentation exposes model and weather-file information. A monthly display alone therefore does not establish that the underlying engine used only monthly inputs; ask how it calculates the result.

Test output: The production report, input record and declared approximation level. Compare different engines only after aligning assumptions and boundaries.

5. Tariff and Financial Model

Use a bill and consumption pattern relevant to the proposed project. Check time-of-use periods, fixed charges, export treatment, demand charges and any battery operation. A reduction in annual imported kWh does not automatically establish the same reduction in the whole bill.

SAM’s published load documentation distinguishes hourly and subhourly data. It warns that scaling a load profile to monthly energy totals does not necessarily reproduce the billed peak for demand-charge analysis. Use the actual tariff’s interval and billing rules rather than assuming all commercial tariffs use fifteen-minute demand periods.

Inspect cost, escalation, degradation, maintenance, financing, discount rate and tax assumptions. Change one input and confirm which outputs recalculate. A controlled spreadsheet can be a valid part of the workflow; test the version handoff rather than declaring every spreadsheet unsuitable.

Test output: The source bill, tariff assumptions, cash-flow basis and sensitivity results. The IRR calculation guide explains why cash-flow definitions matter.

6. Proposal Revision and Handoff

Generate the actual customer-facing output, change a module count or commercial assumption, then regenerate it. Compare the layout, equipment, production, price and financial results across both versions.

Check what updates automatically, what requires a refresh and what is retained for the customer’s earlier option. Integration can reduce re-entry, but it does not remove the need to check synchronization and approvals.

Test output: Two identifiable proposal versions and a change record. Inspect solar proposal software against that specific handoff rather than a general promise of one-click consistency.

7. Data Transfer and Integration Recovery

Test a real record moving between systems, including the fields your team uses. Change a contact or project status, simulate a failed update where the trial permits it, and establish how the team detects and repairs the issue.

Ask about supported API scope, export formats, revision IDs, duplicate handling, permissions and any charges. A product logo in an integrations list is not evidence of the exact workflow you need.

Test output: A field map, successful transfer, known failure behavior and recovery owner.

8. Access, Storage and Exit

Check the permissions each role actually receives. Demonstrate access removal, project reassignment and export of an active project’s input data and deliverables. Ask what remains accessible after cancellation and how retention works.

Cloud and desktop systems require different controls, but neither category is automatically appropriate or inappropriate. Assess backups, authorized access, project continuity, portability and the organization’s own IT requirements.

Test output: A usable export and documented access, retention and backup arrangements.

9. Onboarding and Support

Have a prospective user repeat a representative task after the agreed training. Record time, supervision, corrections and whether the user can explain the assumptions. Set the acceptance target for the actual role and complexity; one working day is not a universal competency standard.

Check support channels, hours, escalation and any written service commitments. If a self-serve trial is unavailable, request sample deliverables, a guided acceptance test or a limited pilot. Trial policy alone does not prove that the product is hiding a difficult workflow.

Test output: The pilot’s completion and error record, unresolved training needs and named support route.

10. Total Cost at Your Volume

Obtain the written plan terms and price the same project, seat and revision volume. Include setup, imagery, storage, integrations, reports, proposal output and other relevant extras. Confirm what consumes a credit and whether revisions really incur additional fees.

A subscription does not automatically include unlimited projects; usage pricing does not automatically charge for every revision. Free tools should be evaluated on their actual scope. For example, SAM’s download page provides desktop software and a free registration key. Its price and delivery format alone do not determine whether it fits your required deliverables.

Test output: An operating-cost worksheet using verified plan terms, with unresolved charges marked for confirmation.

Calculate Costs Without Assuming the Winner

For a hypothetical plan where the initial design and every revision each consume a separately billed credit:

Monthly credits = projects × (1 + revisions per project)
Usage cost = monthly credits × price per credit
Operating cost = base + seats + usage + extras + allocated setup costs

The initial design is included. Omitting it understates the modeled credit count. This assumption must be checked against each vendor’s actual billing definition.

For a separate hypothetical comparison, Plan A costs $200 per month plus $20 for each initial design or revision. Plan B costs $500 per month and covers the modeled volume and revisions, with no additional charges under the scenario. At fifteen projects and two revisions each, their monthly totals are $1,100 and $500.

With identical other costs and two revisions per project, the algebraic break-even is five projects: ($500 − $200) ÷ (3 × $20). At five, both cost $500. This is not an industry break-even threshold or a verified offer from any named vendor.

Measure labor separately. If one tested workflow takes 45 minutes and another takes 12 minutes for the same reviewed task, at thirty tasks the hypothetical difference is 16.5 hours. That is available time under the assumptions, not automatically cash savings, additional sold projects or eliminated staff cost.

Check Accuracy and P90 Claims Before Accepting Them

Ask what a claimed accuracy percentage measures. Agreement with another model is different from validation against metered systems. Request the tested population, weather and system inputs, metering boundary, excluded cases and error metric. Check whether they resemble your project.

Capacity alone cannot establish an annual-energy difference. For a hypothetical 200 kWp system at 1,000 kWh/kWp/year, modeled energy is 200,000 kWh; ten percent of that is 20,000 kWh. At 1,500 kWh/kWp/year, energy is 300,000 kWh and the same percentage is 30,000 kWh. These are arithmetic examples, not measured model errors.

PVsyst’s P50–P90 documentation describes exceedance values under an explicit probabilistic model. It requires uncertainty inputs beyond the base simulation. P90 is the tenth percentile of annual energy under the stated model, rather than a guaranteed minimum or automatic loan approval.

SAM’s published uncertainty help distinguishes interannual weather variability from modeled uncertainty sources and their combined treatment. Its PV uncertainty procedure uses multiple specific-year weather files and defined distributions. A single TMY simulation does not itself demonstrate that this uncertainty analysis has been completed.

Ask whether the number refers to one year, a long-term average or another period, and where the energy is measured. Confirm the reviewing party’s required methodology. Useful energy-model evidence includes resource selection, equipment and geometry, losses, limitations, uncertainty and an independent review where the project requires one.

A Focused Twenty-Minute Demo Script

Use this as a first screen; complex tests and onboarding need a separate pilot. Share permitted inputs in advance and record any preparation the vendor performs.

If an important feature cannot be demonstrated, record why and agree a test. Do not convert an untested claim into a pass because the initial session has ended.

Use Essential Gates Before Weighted Scores

Label each requirement PASS, FAIL, NOT TESTED or NOT APPLICABLE, with evidence. Resolve failed essential requirements first. A tool that cannot produce a required deliverable should not win merely by scoring well on interface or price.

After those gates, adjust these editorial weights to your business:

These weights total 100%. Define your scoring scale before testing and keep evidence beside each score. They are internal procurement choices, not Google quality scores, product accuracy grades or universal weights. Retain unknowns instead of inventing an answer to complete the table.

Pilot the Change Before Replacing the Workflow

Choose a manageable project set, name the approvers and test handoff to the next responsible person. Export active records before migration, verify the export is usable and plan how unfinished projects remain accessible.

Record unresolved items, workaround cost, contract terms and the pilot outcome before committing to a broader rollout. A higher weighted score is useful only after the essential requirements and evidence gaps have been addressed.

To evaluate SurgePV’s solar design workflow, bring the same requirements and representative inputs used for other shortlisted tools. Book a demonstration and agree which tests can be shown and which require follow-up.

Frequently Asked Questions

How do I choose the right solar design software for my business?

Define your project mix, required deliverables and acceptance tests. Run the same representative projects through shortlisted tools, record unresolved requirements, and compare total cost at your actual volume. Reject a failed essential requirement or agree a documented workaround before weighting convenience, speed and price.

What should solar design software include?

The required scope depends on whether you sell proposals, prepare layouts, engineer electrical systems or deliver reviewed energy assessments. Check geometry, equipment, shading, production assumptions, revisions and exports against your responsibilities. A separate specialist tool can be appropriate if the handoff and review process are controlled.

Is free solar design software good enough for professional use?

Price alone does not establish suitability. SAM offers a free software key and desktop downloads, illustrating why free or desktop-based tools should not be dismissed automatically. Check the required workflow, outputs, license terms, support and review arrangements instead of assuming every free tool has the same restrictions.

What is different about residential and commercial software requirements?

Both need defensible site inputs and clear assumptions. Commercial projects may add complex layouts, electrical deliverables, interval tariffs, multiple stakeholders or independent review. Residential projects can also need detailed shading and tariff analysis. Define the actual deliverables rather than treating speed and accuracy as mutually exclusive categories.

How long does it take to learn solar design software?

Measure the time a user needs to complete and explain your representative project at the required review standard. Record supervision, corrections and setup separately from task time. Agree a pilot acceptance target appropriate to the role; this guide does not claim a universal one-day learning curve.

Which integrations should I test?

Test the exact records and fields that must move between your design, CRM, costing and proposal systems. Check updates, failures, permissions, duplicate records and exports. A named integration does not prove that your required fields synchronize or that deleted and revised records are handled correctly.

How accurate is solar design software?

There is no universal accuracy percentage established by the interface, price or time step. Review input quality, modeling scope, validation evidence and uncertainty. Ask whether claimed accuracy means agreement with another model or comparison with suitably measured systems, and whether the tested population resembles your project.

Does a P90 report automatically make a project bankable?

No. P90 describes an exceedance result under a stated probability model and uncertainty assumptions. It is not a guaranteed production floor or automatic lender acceptance. Confirm the period, energy boundary, resource evidence, uncertainty treatment and independent-review requirements for the actual financing process.