Solar Design Outsourcing vs Software: Costs

Last updated: November 2026

SurgePV publishes this post and sells solar design software.

An installer can have plenty of demand and still lose momentum inside the design queue. Sales needs a revised layout today. Operations needs an equipment list. The permit package needs a qualified review, and the internal designer has an unresolved backlog.

The decision is often framed as solar design outsourcing vs software. That framing is incomplete until the team names the deliverable. Preliminary layout software, proposal production, permit drafting, structural calculations, and professional engineering carry different skills and responsibilities.

This guide gives installer-owners and EPC managers a decision model. It compares 4 operating options by cost, capacity, revision speed, retained knowledge, quality control, and accountability.

Screen the Operating Options

The correct choice depends on where the queue forms. A sales team waiting 2 days for every roof layout has a different problem from an engineering manager missing a professional seal. The first problem may respond to a faster internal workflow. The second requires an appropriately qualified person, regardless of which software supports the calculations.

Use this fit matrix for the initial screen:

Software can standardize repeatable work when the team validates its outputs and handoffs. A service provider supplies labor, capacity, and sometimes professional expertise. Internal staff provide company knowledge, customer context, and decision authority.

The procurement question is therefore: Which work should be repeatable inside the company, and which work should be purchased as a controlled specialist deliverable? That question produces a clearer answer than asking whether a monthly license is cheaper than a per-project fee.

Teams evaluating solar design tools should run one normal project and one difficult revision before buying. Teams evaluating a service should send the same pilot cases with frozen inputs and acceptance criteria. Measure accepted output, not first-draft delivery.

Customer-facing preliminary work can benefit from short internal feedback loops. A salesperson can answer a roof-layout change during a live conversation when the design team controls the model. Regulated engineering still needs the review, judgment, and responsibility required in that market.

Define the Deliverable Before Comparing Costs

“Solar design” can refer to at least 5 different project stages. A provider quoting a preliminary array layout is not pricing the same product as a professional issuing electrical and structural documents. Any cost comparison without this distinction will mislead the buyer.

Start with a deliverable register:

Internal software may cover several sales-design outputs without covering the later engineering package. Confirm the offered layout, equipment, shading, production, finance and proposal scope in a representative test. Software does not supply structural engineering, professional seals or project-specific approval.

That boundary matters during sales. A modeled layout can support capacity and customer conversations. It should not be represented as an issued-for-construction package unless the required engineering process has actually occurred.

Outsourced services also differ. GreenLancer markets solar permit design and engineering services. That scope shows why “outsourcing” may mean more than sending a proposal layout to an external drafter.

Write the comparison unit as a complete sentence. For example: “One accepted preliminary design with a 3D roof, module layout, equipment selection, string concept, shading and yield result, financial assumptions, and branded proposal.” A permit package needs a different sentence and acceptance checklist.

GreenLancer’s permit-design page states that structural and electrical engineering requirements vary by project and AHJ and that the assigned engineer must be licensed for the project’s state. Treat this as the vendor’s described service scope, not an independent approval guarantee.

List every exclusion beside the output. Site measurements, field verification, utility applications, structural calculations, professional seals, permit fees, authority responses, and final as-builts should never disappear inside “complete design.”

Then assign the issue status. A draft for customer discussion, approved proposal model, submitted-for-permit set, and issued-for-construction set cannot share an ambiguous filename. Clear status prevents a preliminary output from moving downstream by mistake.

This guide concerns the internal-versus-external delivery boundary. For permanent internal staffing, use the separate software versus hiring a designer assessment.

Build a Cost Model With Your Own Numbers

Public price comparisons age quickly and rarely include the same scope. Build a cost model from your actual operation instead. The aim is cost per accepted project, including internal work around either purchase. The GAO Cost Estimating and Assessment Guide, GAO-20-195G describes documenting assumptions, testing sensitivity and risk, and updating estimates with actual costs. The management worksheet below adapts those general practices; it is not a solar-industry price benchmark.

Use these inputs:

The simplified software-first formula is:

Software-first cost per accepted project = (S + A) ÷ Q + (L × H) + D

Require Q greater than zero; a period with no accepted output has no finite cost per accepted output. Allocate training and nonproductive labor once: do not include the same hours in A, H and the loaded hourly rate. Keep separately modeled delay or lost-contribution scenarios from duplicating already counted labor or overtime.

The simplified outsourcing formula is:

Outsourced cost per accepted project = F + R + V + D

A hybrid model uses both equations by stage. Preliminary work carries internal software and labor. Permit or specialist work carries the external fee and internal review time.

Do not hide rejected or abandoned work. If sales asks for 40 concepts but only 28 reach customer proposal, those 12 concepts still consume capacity. Track cost at 2 levels: cost per completed design task and cost per accepted project stage.

Calculate loaded labor honestly

Hourly pay alone understates internal cost. Include the employer’s statutory costs, benefits, paid nonproductive time, equipment, management, and the share of overhead your finance team uses for staffing decisions. Use the same basis when valuing vendor-management time.

Productive capacity is also lower than paid hours. Designers attend meetings, answer field questions, maintain templates, research equipment, and review colleagues’ work. Measure actual project hours over a representative period rather than assuming every paid hour produces a design.

Add revision cost by cause

One revision rate is not enough. Separate at least 4 causes:

1. Customer changes, such as adding batteries or changing the target offset
2. Site-input corrections after better measurements arrive
3. Equipment changes caused by stock or procurement decisions
4. Preventable design defects that should be corrected under the acceptance terms

Software can make the first 3 faster when the current model remains under internal control. A service provider may manage them well too, but turnaround and commercial treatment depend on the agreement. Preventable defects should be measured separately from legitimate scope changes.

Treat delay as a scenario, not a fake precision number

Delay cost is hard to observe, but ignoring it sets the value to zero. Model a low, expected, and high case. Inputs might include the probability that a delayed proposal misses a customer meeting, the margin at risk, internal idle time, or a permit submission date.

Do not claim that every hour saved creates revenue. Capacity has value only when the team can use it. Link the time saving to a real constraint: faster customer response, more accepted projects, fewer overtime hours, or less purchased overflow work.

The financial model inside SurgePV’s generation and financial tool applies to project economics, not this staffing equation. Keep the business operating model in a separate calculator or management worksheet, then validate whether the proposed workflow changes the measured inputs.

Match the Operating Model to Workload Variability

Average monthly volume hides the capacity problem. A company producing 30 designs every month has a different staffing need from a company producing 10, then 55, then 25. The same 3-month average can produce very different queues.

Plot demand by week and project class. Mark the required turnaround, not only the final due date. A customer proposal may need a same-call adjustment, while a permit package may have a planned review window.

Queue time matters as much as active work time. A 45-minute design task delivered tomorrow has a 1-day business response. A 3-hour task begun immediately may support the meeting this afternoon. Measure request-to-accepted-output time by priority class.

Outsourcing can turn fixed payroll into variable spend, but capacity is not unlimited. Ask a provider how many projects it will reserve, what happens above that band, and whose work receives priority. A generic promise of “scalability” is not a capacity commitment.

Internal software also needs named capacity. Buying a platform does not create a trained operator or remove checking. Map who performs intake, modeling, technical review, proposal approval, and customer revision. If one person owns all 5 steps, software may speed production while leaving the approval bottleneck untouched.

Where enough comparable history exists, test an 80th or 90th percentile week as a staffing scenario, not a universal staffing rule, rather than designing the whole operation around the single busiest week. Keep enough internal capacity for normal work and defined urgent cases. Purchase overflow for peaks that would otherwise sit idle most of the year.

Assign Responsibility With a RACI Matrix

The most expensive workflow gap is often an unowned decision. Software does not accept professional responsibility. A service provider does not automatically own every upstream input or downstream use. The installer or EPC needs a written responsibility map.

RACI means responsible, accountable, consulted, and informed. Tailor the matrix to the contract and local professional rules.

“Tool support” is intentionally not a RACI role. A platform can calculate, store, render, or generate outputs. A person or organization remains responsible for reviewing the result and approving its use.

Keep design authority explicit

Design authority means the person authorized to approve technical intent for the organization. An external drafter can prepare a document without becoming that authority. A professional engineer may carry defined responsibility for a sealed calculation while the EPC still owns customer scope, supplied data, installation, and contract compliance.

Contracts and professional obligations differ by market. Ask qualified legal and engineering advisers to confirm reliance rights, limitation clauses, insurance, seals, and statutory duties. A blog cannot assign liability for a real project.

Control the design basis

The design basis should state the project stage, site data, equipment, applicable requirements, client criteria, assumptions, and exclusions. Both internal and external teams need the same controlled record.

When an assumption changes, log it once and identify every affected output. A module substitution might change physical fit, string limits, energy yield, the BOM, financial results, and proposal visuals. A disconnected workflow makes that impact easy to miss.

Define acceptance

Acceptance is not “the PDF arrived.” Use a checklist with completeness, cross-document consistency, calculation traceability, equipment identity, input conformance, revision closure, and required approvals. Record whether comments are defects, missing inputs, or new scope.

This discipline protects both parties. The buyer gets a measurable deliverable. The service provider avoids unlimited revisions caused by changing customer inputs.

When a Software-First Workflow Fits

A software-first model fits when work is frequent, repeatable, and closely tied to customer response. The internal team controls the model and can revise it without starting a new vendor request.

Consider software-first delivery when most of these statements are true:

• Preliminary layouts follow a repeatable process
• The company has enough monthly volume to retain trained users
• Sales frequently requests changes during customer conversations
• Product and commercial assumptions are company-specific
• Retaining design knowledge matters to the business
• The company can provide technical review and workflow ownership
• Later regulated deliverables already have a separate approved route

A practical workflow begins with controlled site and customer inputs. The user builds the roof or site model, selects equipment, places modules, checks shading, configures electrical intent, reviews yield, and creates the commercial case. The approved proposal model then becomes the basis for the next stage.

SurgePV supports 3D roof modeling, solar array layout, shading analysis, energy-yield modeling, financial modeling, electrical workflow support, BOM output, and proposal generation. A bill of materials (BOM) records the equipment and quantities required for the specified scope. Use a demonstration to check the handoffs, required file formats, and downstream engineering work on your project.

If a demonstration shows that the required outputs share consistent inputs, the workflow may reduce repeated data entry between tools. The buyer should still test every output against its own acceptance rules. Product databases, calculation settings, templates, permissions, and revision practice all need governance.

Use these acceptance tests during a solar software pilot:

1. Build a normal project from the same input pack used today.
2. Record active work time and queue time separately.
3. Change the module model and roof setback after the first review.
4. Check whether layout, strings, BOM, yield, finance, and proposal remain consistent.
5. Ask a second user to find the approved version without verbal guidance.
6. Export the customer deliverable and run the normal technical review.
7. Document which downstream permit or engineering steps still occur elsewhere.

Do not choose software only from a polished vendor demonstration. Bring one awkward roof, a real tariff case, and the revision that repeatedly causes rework. A strong demo lets your team operate the workflow and expose gaps.

When Outsourced Solar Design Fits

Outsourcing fits when the company needs variable capacity, defined production support, unfamiliar-market knowledge, or professional disciplines that do not justify permanent staffing. The scope can cover preliminary production, permit documents, engineering, revisions, or as-built records. Treat each as a separate purchase.

Use an outsourced model when several of these conditions apply:

• Demand is too irregular to keep internal capacity occupied
• A short peak would otherwise create a damaging queue
• The project needs a discipline or jurisdiction the internal team lacks
• The deliverable is standardized enough to specify and inspect
• Customer changes do not require immediate model access
• The provider can supply named competence and appropriate professional authority
• Data, intellectual property, and handover terms are acceptable

The buyer still owns vendor management. Someone must prepare inputs, answer questions, review outputs, resolve comments, and accept files. Include that internal time in the cost model.

Service-level claims need precise definitions. Unirac’s plan-set service page advertises a 24-hour turnaround after onboarding as checked in November 2026. That is a vendor’s stated service level, not an industry benchmark. Buyers should confirm intake cutoffs, eligible project types, business hours, revision classification, and the event that stops or restarts the clock.

Test a provider with one typical project and one realistic exception. The exception may include a late equipment change, a difficult roof, incomplete service-panel data, or an authority comment. Score the questions asked, assumptions recorded, cross-sheet consistency, and revision closure.

Require native-file and termination handover terms where those files matter. A library of final PDFs may not let a new team efficiently revise an active portfolio. Define file ownership, permitted reuse, retention, deletion, and access when the contract ends.

Do not route an urgent task outside simply because the internal queue is visible. Compare the full external queue: intake review, clarification, production, buyer review, revision, and acceptance. Outsourcing works best when the interface between teams is engineered as carefully as the technical deliverable.

How a Hybrid Workflow Works

A hybrid workflow keeps the shortest customer feedback loop inside and buys specialist or peak capacity outside. This is often the clearest answer for an installer that needs fast proposals but does not maintain every engineering discipline in-house.

The stage gate might look like this:

1. Internal intake: Sales records the site, customer demand, bill or load data, equipment constraints, and commercial assumptions.
2. Internal preliminary design: A trained user creates the roof model, layout, shading result, electrical concept, yield estimate, and financial case.
3. Customer approval: The salesperson presents a controlled proposal and records requested changes in the design workspace.
4. Technical freeze: The EPC approves the equipment basis, layout revision, scope, and known site assumptions for downstream work.
5. External permit or engineering package: A qualified provider receives the controlled input pack and produces the contracted deliverables.
6. Internal acceptance: The EPC reviews completeness, customer requirements, constructability, and cross-document consistency.
7. Professional release: The responsible professional reviews, signs, or seals documents where the applicable rules require it.
8. Change control: Any customer, site, equipment, or authority change returns through a named impact review.

The freeze does not mean the design can never change. It identifies the revision that the external team priced and used. New information then creates a controlled change rather than silently replacing an attachment.

Create a handover pack

The external team should receive a defined package, not an email thread. Include:

• Project identity, address, jurisdiction, and utility
• Site records and confidence level for each measurement
• Approved preliminary layout and revision
• Equipment models and acceptable alternatives
• Electrical service information and known constraints
• Energy and commercial assumptions when relevant to scope
• Required codes, client standards, and authority documents
• Deliverable list, file formats, issue status, and due dates
• Open assumptions, questions, and exclusions
• Named contacts for technical and commercial decisions

The internal solar proposal software output is customer-facing. It should not be used as the only engineering handover if the external provider needs calculations, native geometry, surveys, or jurisdiction-specific data.

Use an impact matrix for revisions

Every changed input should point to affected outputs:

This matrix prevents the hybrid model from splitting into 2 independent designs. One side should not revise equipment while the other continues from a superseded model.

A hybrid process also benefits from regular defect review. Group corrections by root cause: bad input, unclear scope, internal modeling error, external production error, changed customer request, or authority interpretation. Fix the interface rather than arguing about every isolated comment.

Compare Worked Monthly-Volume Scenarios

The examples below are illustrative management models. They are not market-price estimates, vendor quotes, or promises of savings. Replace every input with your own measured cost, time, volume, and acceptance rate.

Scenario 1: Steady residential preliminary-design volume

Assume an installer completes 40 accepted preliminary designs each month. The illustrative inputs are:

• Software and allocated administration: $1,600 per month
• Loaded internal cost: $52 per hour
• Internal time: 1.4 hours per accepted design
• Expected delay allocation: $10 per accepted design

Software-first cost:

$1,600 ÷ 40 + ($52 × 1.4) + $10 = $122.80 per accepted design

Now model an outsourced preliminary-design option:

• Service fee: $115 per design
• Expected paid revision cost: $12
• Internal intake and review: 0.55 hours at $52
• Expected delay allocation: $18

Outsourced cost:

$115 + $12 + (0.55 × $52) + $18 = $173.60 per accepted design

In this invented scenario, the software-first route costs less. The decision is still not complete. The buyer must confirm that the internal team has capacity, the outputs have equal scope, and the revision time supports sales.

Both figures are calculated from the stated assumptions, including internal review and delay allocations. Neither is a SurgePV price or a service-provider quotation.

Scenario 2: Irregular commercial opportunity flow

Assume a small EPC sees 2 accepted preliminary commercial designs in one month and 11 in the next. A permanent specialist may sit underused during the low month and become overloaded during the peak.

Model a 3-month period rather than a single month:

The hybrid option may cost more per quiet-month project but protect the peak without adding permanent headcount. That value should appear as avoided backlog, reduced overtime, or protected bid dates. Do not label it “savings” without observing one of those outcomes.

Scenario 3: Permit and engineering work

An internal preliminary-design platform and an outsourced permit-engineering package should not be compared as equal products. Model them as successive stages:

Total project design cost = internal preliminary stage + outsourced permit or engineering stage + internal acceptance + expected revisions

For example, the internal stage might supply a controlled array layout, equipment basis, shading result, and proposal. The service scope might add jurisdiction-specific plans, engineering calculations, responses, and professional review. The combined cost is meaningful because both stages are necessary for the chosen workflow.

Find the break-even volume

If scope and quality are equal, a simplified break-even quantity can guide a pilot:

Break-even Q = monthly fixed software and administration cost ÷ (outsourced variable cost − internal variable cost)

Suppose fixed internal software and administration cost is an illustrative $1,600. Outsourced variable cost is $173.60, and internal variable cost excluding fixed allocation is $82.80.

Break-even Q = $1,600 ÷ ($173.60 − $82.80) = 17.6 accepted designs per month

For these inputs, 18 accepted designs is the first integer quantity above break-even. Require outsourced variable cost to exceed internal variable cost before using this formula; a zero or negative difference yields no positive break-even volume under this model. Stress-test the answer. If quality, scope, or turnaround differ, the mathematical break-even is not a decision. Use low and high cases for labor time, revision rate, accepted volume, and delay.

The strongest ROI statement is retrospective. After a 30- or 60-day pilot, compare measured request time, active work time, revision count, accepted output, and purchased overflow with the pre-pilot baseline.

Run a Controlled Pilot Before You Commit

A pilot turns feature claims and service promises into operating evidence. Use the same cases, frozen inputs, and acceptance standards for each feasible option.

Choose 3 project cases:

1. A common project that represents most monthly volume
2. A difficult but recurring project, such as a multi-plane roof or commercial tariff case
3. A revision case that changes equipment, geometry, or customer assumptions after the first draft

Do not select only the cleanest project. The purchase must survive the work that causes your current queue.

Score the pilot using a weighted matrix:

These weights are a suggested management tool, not an industry standard. Change them before the pilot based on your constraint. A sales-led installer may weight response time higher. An EPC issuing construction documents may weight technical acceptance and traceability higher.

Pilot the whole operating path

For software, include training, template setup, technical checking, customer revision, and export. For outsourcing, include intake, clarification, vendor production, internal review, correction, and handover. For a hybrid, test the external handoff from the actual internal model.

Record timestamps without turning the pilot into surveillance. The purpose is to identify waiting, repeated entry, unclear ownership, and avoidable correction. Separate active work work from time spent in a queue.

Define failure before the test

A pilot should have stop conditions. Examples include an unresolved data-security issue, missing professional authority, inability to provide required native files, repeated equipment mismatch, or an acceptance defect that creates installation risk.

Also define remediation. A failed template or poorly configured rule may justify one corrected run. A provider concealing subcontractors or a product claiming a regulated capability it does not supply requires a different response.

Review commercial terms after technical fit

Price the demonstrated workflow, not the sales description. Confirm included users, project limits, support, renewal terms, training, revision classes, rush work, taxes, and termination rights. Match the contract scope to the validated acceptance checklist.

At the end, select the operating model with the best controlled result for your demand pattern. A cheaper option that repeatedly misses the customer or permit workflow is not lower cost.

Make the Decision

Choose internal software when repeatable preliminary work is frequent, customer feedback must be fast, and the company can own technical review. Choose outsourced production when demand is irregular and the deliverable is precise enough to contract and inspect. Choose qualified engineering support when the project requires competence, review, or professional authority the internal team does not hold.

For many installers, the answer is a hybrid. Internal users control sales-stage layouts, shading, energy, financial assumptions, and proposals. A specialist then delivers the regulated permit or engineering scope under a defined agreement.

Take these 3 actions:

1. Write one-sentence deliverables and exclusions for each project stage.
2. Measure cost per accepted output, including internal review, revisions, and delay.
3. Pilot a normal case and a difficult revision before signing a long-term commitment.

Confirm the actual internal preliminary-design scope in the offered SurgePV configuration. Retain qualified engineering and the required external approvals for stages outside that scope.

Document the selected boundary as an operating policy. Name the project stages that stay internal, the work classes eligible for outsourcing, and the person who approves every release. Add a review date so the model changes when volume, staff competence, target markets, or project complexity changes.

Do not force every project through the same route. A straightforward residential proposal may stay inside from intake through customer approval. A commercial site with an unfamiliar structural system may move to a specialist before the layout is promised. Routing rules should respond to risk and capability, not employee preference.

Track 5 measures after implementation: request-to-accepted time, active work internal hours, revision count by cause, first-pass acceptance, and cost per accepted output. Review the measures by project class. A portfolio average can hide a slow commercial workflow behind many fast residential jobs.

The decision is reversible when project data and acceptance criteria remain under control. A company can bring repeatable work inside after demand grows, or add an external lane when a peak forms. Clear records make either change safer.

Bring the selected scope and acceptance checklist to the purchasing discussion, so the price covers the workflow your team intends to use.

Bring a normal project and a difficult revision to a SurgePV demo to assess the internal design workflow before allocating outsourced work.

Frequently Asked Questions

Is solar design software cheaper than outsourcing?

Solar design software can have a lower cost per preliminary design when a trained internal team has steady volume. Outsourcing can cost less when demand is irregular, specialist work is infrequent, or the company cannot keep an internal designer productively occupied. Compare total accepted-project cost with your own labor, subscription, service, revision, and delay inputs.

When should a solar installer outsource design?

Outsource when demand temporarily exceeds internal capacity, a project needs expertise the team does not hold, or a regulated deliverable requires a qualified professional. Keep scope, inputs, checking, revision rules, and final acceptance explicit.

Can software create permit-ready solar drawings?

Some products or services may generate parts of a permit package, but capability and acceptance vary by product and jurisdiction. SurgePV should not be treated as a replacement for structural engineering, professional stamps, jurisdiction-specific permit review, or detailed construction drawings. Confirm every required sheet and responsible professional with the authority having jurisdiction.

Who is responsible for engineering errors in an outsourced design?

Responsibility depends on the contract, professional duties, jurisdiction, and who approved the issued deliverable. The installer or EPC should not assume that outsourcing transfers every obligation. Define design authority, checking, professional liability, reliance rights, and acceptance in the agreement, then obtain legal and engineering advice for the applicable market.

What solar design work should remain in-house?

Many installers retain customer discovery, site-input validation, product selection, sales-stage layouts, commercial assumptions, proposal control, and final acceptance. Work can move outside only after the team defines what the provider may decide and what requires internal approval.

What should an outsourced solar-design service agreement include?

Include deliverables, exclusions, input requirements, codes, file formats, turnaround definitions, revision classes, acceptance criteria, professional responsibility, confidentiality, data handling, native-file rights, escalation, pricing, capacity limits, and termination handover. Attach a sample acceptance checklist to remove ambiguity.