9 Questions to Ask Before Buying Solar Software

A growing solar company can accumulate software for perfectly understandable reasons. The questions to ask before buying solar software begin with the work, not the product. Sales needs a quicker handoff. Design needs fewer incomplete briefs. Operations needs current project status. Finance needs a clean commercial record. A demonstration can make the missing steps look unusually polite.

The danger arrives after the demonstration. A feature can work while the surrounding workflow still fails. The address may transfer but the meter identifier does not. A layout may update while the proposal keeps an older assumption. An export may exist but omit the decision history needed for migration. Staff can receive accounts without gaining the judgment or review authority required for the work.

Software buying should begin with the operating decision, not with a category or a feature grid. The nine questions below are designed for an owner or operating leader who needs evidence strong enough to choose one of four honest outcomes: buy, run a bounded pilot, defer, or reject.

This is a desk-research buying method, not legal, privacy, cybersecurity, accounting, tax, engineering, utility, permitting, or contract advice. Requirements vary by company, project type, data, vendor, agreement, and jurisdiction. Bring the responsible specialists into the decision where their authority is required.

What should a growing solar company decide before evaluating software?

A growing solar company should define one constrained workflow, the project classes it covers, the roles involved, the current failure, and the evidence that would justify change. The decision is not “Do we like this product?” It is whether a tested operating method deserves purchase, a narrower pilot, deferral, or rejection.

Growth is context, not evidence. More leads may expose a slow intake process, but software will not repair an unclear acceptance rule. More designers may expose version confusion, but an added platform can create another version to reconcile. Entering commercial work may expose new data and review needs that a residential tool was never asked to handle.

Write a purchase statement before meeting vendors:

We are evaluating software to support [named workflow] for [project classes and markets] because [observed failure] affects [named decision or handoff]. We will judge options using [test evidence]. We will not treat [excluded workflow, output, or authority] as part of this purchase.

That statement forces four useful boundaries. It names the work. It separates an observed failure from a theory about its cause. It identifies evidence before anyone sees a polished interface. It also protects adjacent systems and specialist work from being quietly pulled into scope.

Name a decision team as well. The owner who approves spend cannot represent every daily handoff. Include a real user, the owner of the affected workflow, a person accountable for released customer or technical work, the administrator, and the person responsible for security and data questions. Add legal, privacy, finance, engineering, utility, permitting, or contract review when the intended use reaches those areas.

The UK Technology Code of Practice is written for government technology work, not private solar procurement. Its question order is still useful: define user needs, consider open standards, examine security and privacy, plan integration and data use, define purchasing, and manage the technology through its lifecycle. A solar company can borrow that discipline without claiming the framework decides its purchase.

Which questions should teams ask before buying solar software?

Ask nine questions that expose the operating system around the product: workflow constraint, project fit, source-of-truth ownership, data exchange, human review, security, implementation, full cost, and exit. Require a document, demonstration, test result, contract answer, or named owner for each response. An unsupported yes remains an open item, not evidence.

These are not nine ways to make every product look weak. A focused product may answer some questions by defining an honest boundary. “We do not own that field” can be a better answer than a vague integration claim. “This output still requires your reviewer” can be safer than an assurance that the workflow is automatic.

1. Which workflow constraint are we actually buying against?

Start with the moment the work becomes unreliable, slow, or hard to reconstruct. “We need automation” is not a constraint. “Design receives projects without an accepted consumption record, so staff return the brief or create an untracked assumption” is specific enough to investigate.

Follow the project from source evidence to released output. Note where a person prepares a file, enters a field, interprets an exception, waits for approval, corrects a mismatch, or communicates a change. The product only deserves credit for work it can actually affect. If the real cause is an undefined intake threshold or missing decision owner, correct that before buying around it.

Ask the vendor to demonstrate the affected segment and its upstream and downstream handoffs. Ask your team whether the proposed workflow removes work, moves it to another role, or changes the evidence needed. Moved work can be worthwhile, but it must be visible. The focused guide to workflow costs in solar platforms owns the deeper cost inventory.

2. Which project classes and exceptions must the software handle?

A generic residential sample reveals little about a company that sells commercial systems, storage, multi-meter work, ground-mount projects, or projects across several authorities. Define the intended project envelope in plain language. Include location, project class, typical source materials, equipment context, output, reviewers, and the exceptions that occur often enough to matter.

Then choose test cases that expose meaningful variation. One might include incomplete interval data. Another may require a system-size revision after the first proposal. An exception could involve a substitute module, an obstruction discovered after remote modeling, a customer request for an additional scenario, or a handoff to a qualified external reviewer.

Do not ask whether the platform “supports commercial.” Ask what the words mean in the tested workflow. Can it preserve multiple meters and their sources? Can reviewers distinguish current inputs from provisional assumptions? Can the relevant output be identified and exported? Which work remains outside the platform? A scoped no can lead to a point-tool decision. An unqualified yes needs evidence.

3. Which system owns every important field and document?

Growing teams often have several plausible sources of truth. The CRM owns the customer address until a survey corrects it. The design record owns the current module count, while the proposal contains a customer-visible version. The accounting system owns invoices. The contract repository owns executed terms. Calling all of them “integrated” does not decide which one controls a disagreement.

Create a field map for project identifier, customer identity, site address, consumption records, meter identifiers, design revision, equipment selection, pricing basis, proposal version, approval state, and external correspondence. For each object, name the authoritative source, allowed editors, downstream copies, correction path, and archive or retention owner.

The FTC’s business guide to protecting personal information tells businesses to take stock of the information they hold, limit what they keep, protect it, dispose of unneeded information properly, and plan for incidents. It also tells them to examine access by employees and outside service providers. That supports asking where customer and employee information enters and who can reach it. It does not decide a company’s legal duties or retention rules.

If two systems can edit a decision-critical field, define reconciliation. If neither owns it, the purchase may need a process decision before an integration. For a wider map of duplicate tools and project fields, use the focused solar software stack consolidation guide.

4. How will information enter, leave, and recover when a connection fails?

An integration label hides the part operators eventually meet: field mapping, timing, identity matching, error reporting, permission, retries, monitoring, and recovery. Ask for the exact objects and directions involved. “Connects to CRM” could mean a link, a one-way contact import, a scheduled transfer, or a supported two-way synchronization with conflict rules.

Use a handoff record with source object, destination object, field owner, trigger, expected timing, failure signal, retry owner, and correction method. Include files as well as APIs. A usable PDF export is different from a structured project export. A spreadsheet can preserve fields while losing attachments, versions, comments, or approval history.

Open standards and the ability to integrate and adapt are explicit parts of the UK technology buying framework. For a solar company, the practical question is whether the chosen method preserves the project objects the business needs. Open format alone does not prove semantic compatibility. Test imports and exports with actual field meanings and compare the result with the source.

Require a failure demonstration where possible. Disable a connection, change an identifier, submit a duplicate, or reject a record. Observe where the failure appears and who can repair it. Happy-path synchronization demonstrates transfer. Recovery demonstrates whether the operating team can live with the connection.

5. Which reviews, exceptions, and release decisions remain human?

Software can make a project record easier to inspect without becoming the authority that approves it. Ask which outputs are preliminary, customer-facing, procurement-related, permit-oriented, or intended for construction. Then name the person or external body whose judgment controls each release.

Build an exception path beside the normal path. What happens when roof information conflicts, equipment is unavailable, a proposed revision changes downstream outputs, a utility answer remains open, a financing input is missing, or a customer requests a claim that the evidence does not support? The platform should not receive credit for hiding the exception behind a completed status.

Review controls should be demonstrable. Look for current version identity, reviewer, decision, exceptions, affected outputs, correction owner, and release purpose. If an approval is represented inside the product, confirm what that status means in the operating procedure and contract. An internal checkbox does not replace an engineer, authority, utility, lender, insurer, or another responsible decision owner.

6. What security, privacy, and access evidence can the vendor provide?

Security questions need a responsible reviewer and a defined use case. Start with the information and functions the product would receive. Customer identity, site information, bills, interval data, financial assumptions, employee accounts, project documents, and external integrations can carry different risks and obligations. Do not paste a generic questionnaire onto an undefined data flow.

NIST Cybersecurity Framework 2.0 is presented by NIST for industry, government, and other organizations seeking to reduce cybersecurity risk. It offers risk-management context, not a product certificate. Ask the vendor for current evidence that matches the service, scope, and configuration you intend to use, then have the appropriate security and privacy reviewers assess it.

The UK NCSC’s cloud security principles apply to SaaS as well as cloud platforms. The NCSC says users still need to consider secure configuration separately. That distinction matters. A provider can describe its controls while the customer remains responsible for accounts, roles, authentication choices, sharing settings, connected applications, and administrator practices.

Ask about identity and authentication, role granularity, administrator activity, logs available to customers, backups and recovery, incident communication, subprocessors, data locations, deletion, and support access. Match every answer to its evidence date and scope. CISA’s SCuBA project is a concrete example of configuration baselines for Microsoft 365 and Google Workspace. It is not a certification for solar platforms, but it demonstrates why the actual configuration deserves its own review.

7. Who will implement, administer, train, and support the new method?

The sentence “the team will own it” usually means nobody has accepted the work. Name an implementation owner, workflow owner, administrator, data or migration owner, training owner, support contact, and decision owner. One person may hold several roles in a small company, but the responsibilities still need names.

Implementation includes configuring fields and roles, cleaning initial data, defining project templates, validating outputs, documenting exceptions, setting support routes, and deciding when the old process stops. Training should follow role decisions rather than showing every screen. A salesperson needs the accepted intake and correction path. A reviewer needs evidence, version, exception, and release controls. An administrator needs account, permission, integration, monitoring, and offboarding procedures.

Ask the vendor what assistance is included, what is separately scoped, which customer resources are required, and how unresolved configuration issues are handled. Confirm those answers in the current written quote or agreement. The deeper solar software implementation guide owns rollout planning. This purchase interview only establishes whether implementation responsibility is visible enough to make a decision.

8. What will the software cost to operate, not merely license?

Start with the written quote and its units. Then add implementation, configuration, migration, integration, training, administration, support, review, parallel operation, exception handling, and exit work. Keep cash expense separate from internal capacity. Existing salary is not automatically a new cash cost, and time released by software is not automatically financial savings.

The SBA business-management guidance places recurring and nonrecurring costs inside cost-benefit analysis. That is enough to challenge a subscription-only comparison. It does not provide accounting treatment or a solar-software estimate. The buying team should work with its responsible finance or accounting reviewer before turning workload observations into a financial conclusion.

Record cost confidence as quoted, observed, estimated, or unknown. A vendor quote can support the license amount and stated services. It does not support the customer’s internal migration or review effort. A timed test can observe active work for the selected cases, but it does not prove future capacity across a different project mix.

If the decision depends on a numeric result, declare every input, unit, source, formula, and assumption and compute it independently. This guide intentionally presents no universal payback, labor saving, productivity gain, or software return. The correct output may be a cost range with material unknowns, or a decision to collect better evidence before purchase.

9. How will the company leave without losing operational memory?

Exit belongs in the purchase conversation because project history outlives product enthusiasm. Ask what can be exported, in which format, with which attachments, versions, comments, approvals, audit records, and identifiers. Ask how long access remains after termination, how deletion works, what assistance costs, and which contract terms control the transition.

Test an export before buying when the decision is material. Open it outside the product. Can another person identify the project, accepted inputs, current output, assumptions, decision history, open exceptions, and customer-visible version? Can structured fields be imported elsewhere without losing their meaning? A folder of PDFs may preserve documents while making portfolio-level reconciliation impractical. A table export may preserve fields while dropping evidence.

Exit also exposes ownership. Someone must decide what the company is required or permitted to retain, where the retained record lives, who can access it, and how old accounts are removed. Those are legal, privacy, security, contract, and operational questions for the responsible reviewers. A vendor statement that the customer “owns the data” does not answer the retrieval and transition details.

How should a solar company test vendor answers before signing?

Test vendor answers with a frozen input pack, representative project, meaningful revision, decision-critical exception, real role handoff, and export. Record every step outside the product and every unresolved claim. Use prewritten stop conditions. The test may support purchase, a narrower pilot, deferral, or rejection; it does not have to produce a winner.

Use a bounded process so the evidence remains comparable:

1. Freeze the decision contract. Record the workflow, project classes, exclusions, buying team, must-answer questions, and acceptable outcomes. Do this before the demonstration changes what the team thinks it needs.
2. Prepare the same input pack. Use identifiable source files, dates, known gaps, and allowed assumptions. Remove unnecessary personal data and follow the company’s approved handling method.
3. Define the expected handoffs. Name the roles, systems, fields, documents, reviews, and release purpose involved. Include one downstream correction so change propagation is visible.
4. Run the normal case. Let actual role representatives perform or observe the work. Record setup assistance and off-screen work instead of treating vendor intervention as invisible.
5. Run a revision and exception. Change a decision-relevant input, introduce a conflict, or reject a handoff. Observe detection, correction, ownership, and affected outputs.
6. Inspect access, administration, and export. Review roles and logs with qualified owners, create and remove a test account, export the project record, and verify the retained content outside the platform.
7. Close every question with evidence or an owner. Classify each answer as verified in test, supported by current documentation, contract-dependent, customer-dependent, or unknown. Then choose buy, pilot, defer, or reject.

The focused solar software trial guide can carry the detailed trial plan after the team approves one. This guide stops at the purchase gate. It should not expand a short evaluation into an open-ended implementation project simply because people have already invested effort.

Do not average a blocking failure into a feature score. If the intended use requires an export that preserves project identity and the test export cannot do it, eight attractive features do not repair that condition. The buying team can narrow the intended use, change the operating design, seek a contract commitment, defer, or reject.

What should the final software purchase record contain?

The final purchase record should preserve the workflow decision, evidence reviewed, project tests, unresolved items, responsible owners, costs by evidence state, contract dependencies, implementation boundary, exit result, and chosen outcome. It should explain why the company selected buy, pilot, defer, or reject and what would trigger reconsideration.

Copy this record into the company’s decision system.

Copy-ready solar software purchase record

Keep vendor claims and buyer observations in separate columns. “Supports export” is a vendor claim until the team receives the format, opens it, and checks the needed objects. “User completed the normal case” is an observation bounded to the tested person, project, configuration, and assistance. Neither statement predicts organization-wide adoption.

Illustrative example: a design-to-proposal purchase gate

This is an invented workflow example, not a customer case, recommendation, quote, test result, price, saving, capacity finding, contract term, or SurgePV outcome.

An installer is considering a platform for residential design-to-proposal work. The observed problem is revision control: a field correction can reach the layout while the sales team still holds an older proposal. The intended scope excludes permitting, construction release, accounting, contract management, and service operations.

The buying team freezes an input pack with site identity, available roof evidence, consumption material, equipment context, a proposed option, and declared gaps. The normal case creates a model and proposal. The revision changes a roof obstruction and module choice. The team records which outputs change, what requires review, and whether the earlier proposal is visibly superseded.

The export preserves the current project output but not one piece of the decision history the company expected. The security reviewer also has an open question about administrative logging. The team does not score those items as partial passes. It records owners and chooses a bounded pilot limited to non-released proposal preparation, subject to export and logging resolution. Buy, defer, or reject would also be legitimate if the evidence supported them.

This example works because the decision stays narrower than the product. The company does not claim that the platform will increase sales, eliminate errors, create capacity, satisfy external approvals, or fit project classes it did not test.

Where can SurgePV fit, and where does software stop?

SurgePV can support connected roof modeling, array layout, shade analysis, energy-yield and financial modeling, electrical workflow, material-list output, and proposal creation. A buyer must still test project fit, data, handoffs, access, costs, implementation, contracts, and exit. Responsible people retain input acceptance, technical review, customer claims, and external approval.

SurgePV’s repository-documented scope begins with three-dimensional roof and array work. It also includes shade evaluation, energy-yield and financial scenarios, electrical-workflow support, bill-of-materials output, and proposal creation. This first-party scope can define what to test. It cannot prove that the platform fits a buyer’s project mix, existing systems, security requirements, agreements, team, or economics.

Results depend on source data, assumptions, equipment models, configuration, and review. Outputs support design and documentation workflows but do not replace approval by the responsible engineer, authority, lender, insurer, or utility.

During evaluation, use one project identifier across inputs, model, output, revision, and decision record. Ask who accepts each input, which scenario is current, which customer-visible document corresponds to it, and what happens after a change. Inspect the files and fields that leave the platform. Confirm current product access, implementation scope, pricing, support, data terms, and contract language in writing with the responsible owners.

The platform stops wherever the evidence, authority, or contract belongs to someone else. It does not determine local requirements, verify a roof from incomplete source material, approve electrical work, decide customer eligibility, interpret tax treatment, certify security, accept a contract, or guarantee a commercial result. Software buying is better when those boundaries are visible before signature.

Frequently Asked Questions

Who should participate in a solar software buying decision?

Include the workflow owner, daily users, a reviewer responsible for released work, the person who owns security and data questions, the administrator, and the commercial decision owner. Add specialists for contracts, privacy, engineering, finance, tax, utility, or permitting matters when those issues affect the intended use.

Should a growing solar company buy one platform or several point tools?

Start with the project workflow and source-of-truth map, then compare the operating burden of each option. One platform may reduce transfers but still leave specialist needs. Several tools may fit distinct jobs but add reconciliation, access, support, and failure-handling work. The right boundary depends on observed project evidence.

How many projects should a solar software test include?

There is no universal project count. Choose enough work to cover the intended project class, a meaningful revision, a decision-critical exception, and a handoff between real roles. A larger sample does not repair an easy test. Record the cases, starting evidence, reviewers, missing information, and stop conditions before testing.

What if a vendor cannot answer a security or data-export question?

Record the unanswered item, why it matters, who must resolve it, and whether it blocks the intended use. Do not turn missing evidence into an assumed pass. The decision may be to narrow the use, request qualified review, run a controlled test, defer the purchase, or reject the option.

Can SurgePV decide whether its software is right for a solar company?

No. SurgePV can explain and demonstrate its documented design and proposal scope. The buyer must test its own projects, data, controls, contracts, costs, integrations, reviewer responsibilities, and exit requirements. Responsible professionals and external authorities retain every approval that the project, market, or organization requires.

A useful software purchase record can end with “not yet.” That answer protects the company from buying around an unmeasured problem, while leaving a clear route back when evidence changes. A purchase is earned when the workflow, test, responsibilities, costs, and exit make sense together, and when the unresolved items are visible to the people who own them.