Back to Blog
solar business 13 min read

Scaling From 10 to 50 Solar Installations Per Month

A systems-focused playbook for solar companies moving from founder-led delivery to a controlled multi-team operation.

Rainer Neumann

Written by

Rainer Neumann

Content Head · SurgePV

Published ·Updated

Quick Answer

Scaling from 10 to 50 solar installations per month requires a repeatable operating system: clear roles, controlled design releases, capacity-aware scheduling, documented exceptions, and feedback that improves the next project.

Moving from 10 to 50 solar installations per month changes the nature of a company. At a smaller volume, founders and a few experienced people can carry context across sales, design, permitting, procurement, fieldwork, and customer questions. At a higher volume, memory becomes a fragile operating system. A missed note, unrecorded scope change, or unclear drawing can be replicated across multiple crews before anyone recognizes the pattern.

The answer is not bureaucracy for its own sake. It is an operating system that makes ordinary work easy to complete correctly and makes unusual work easy to see. That system should preserve accountability, site-specific judgement, safety, and customer clarity as the business grows.

Direct answer

To scale from 10 to 50 installations, replace founder memory with explicit stage gates, ownership, version control, and capacity planning. Increase releases only when the next team has the information and capability to act safely and correctly.

Recognize the transition you are making

The early-stage company often succeeds because it is responsive. A customer can call the founder, a designer can walk into the warehouse, and an installer can resolve a detail directly with sales. Those behaviors can remain valuable, but they do not scale if decisions are not captured. When the same question has to be answered repeatedly, it is a signal that a role, checklist, or project record is missing.

At 50 installations per month, different projects will be at different stages every day. The business needs a shared answer to basic questions: Which version is approved? Who owns the next customer contact? Is this project ready for permit submission? What equipment was released? What changed after the contract? Which issue needs engineering, management, or utility follow-up? Without visible answers, people solve problems locally and create new uncertainty elsewhere.

The U.S. Department of Energy notes that solar project costs include non-hardware activities such as permitting, customer acquisition, installation labor, and other business processes in its soft-cost overview. The implication for a growing company is practical: capacity is not simply crew count. It is the ability of the full system to turn verified information into completed work.

Define a project lifecycle with real entry criteria

Write the lifecycle in language that every role can use. A simple version may include qualified opportunity, site evidence collected, preliminary design, customer decision, technical review, permit or authority work, materials released, installation ready, installed, inspection or utility steps, and closeout. The exact labels are less important than their meaning.

For each stage, define four things: the owner, the required inputs, the evidence created, and the event that releases the project to the next stage. “Design complete” is not a criterion. “Design version identified, required survey evidence linked, equipment selection reviewed according to company rules, and open technical issues assigned” is closer to one.

Make blocked work visible rather than leaving it in a generic “in progress” column. A project blocked by a customer document, roof issue, utility question, authority revision, payment decision, or material availability needs a different next action. The block reason should have an owner and a review cadence. This creates more truthful forecasts than a spreadsheet where every job shares the same estimated completion date.

Build roles around decisions, not job titles

As headcount grows, responsibilities overlap unless the company describes who decides what. Sales may own discovery and customer expectations. Design may own a preliminary configuration and documentation package. Engineering or qualified reviewers may own technical approvals within their authority. Operations may own scheduling and procurement release. Field leadership may own site execution and safety controls. Customer success or project management may own communication after sale.

The goal is not to create rigid silos. It is to ensure that a material decision has a known owner and that a handoff does not rely on verbal context. Use a responsibility matrix for high-risk or recurring decisions: equipment substitution, scope change, roof issue, electrical upgrade, permit correction, inspection response, and schedule commitment. State who recommends, who approves, who must be informed, and what evidence is required.

Do not give a role an approval it is not competent or authorized to make. Scaling should increase access to expertise, not spread technical or legal decisions to the nearest available person. When an issue exceeds the routine process, route it to the qualified role and document the resolution.

Make sales-to-operations handoff a controlled release

The sales handoff is one of the first places growth becomes visible. A contract or customer acceptance is important, but it does not automatically make a project ready for construction planning. The operations team needs the accepted scope, customer objectives that affect delivery, site and load evidence, disclosed constraints, selected options, financing or payment status as applicable, and a record of exclusions or contingencies.

Use a handoff review rather than an email forwarding ritual. The receiving owner should be able to accept the package, request missing information, or place the project in an exception lane. Requiring this acknowledgement prevents a project from being “sold” but invisible to the people who must deliver it.

Customer-facing visual documents can be helpful in this step. Solar proposal software can support a consistent record of what was presented, including version references and assumptions. It does not replace a contractual review, a site survey, or the technical work required before installation.

Control designs, changes, and materials

A company at higher volume needs a dependable design-release rule. Give designs unique identifiers, record their status, and make the current released version unmistakable. If a customer changes panel placement, equipment, battery scope, or another material part of the project, capture the request before it reaches procurement or a crew. Then assess whether design, engineering, permitting, price, timeline, or customer documentation needs to change.

This does not mean no one can make a field decision. It means a field discovery that changes scope triggers a known process. The crew should know who to call, what photos or notes to capture, whether work may continue safely, and how the project record will be updated. That is safer than a sequence of informal messages that never reaches the final closeout file.

Procurement should be linked to a released design and a clear substitution process. Inventory availability is a commercial fact, not a technical authorization. If an alternative component is considered, the responsible reviewers should assess compatibility, documents, customer communications, applicable approvals, and warranty implications before release. A generation and financial analysis workflow can help maintain coherent scenarios, but the team must still govern which design and assumptions are current.

Forecast capacity from readiness, not hope

Leaders need a forward view of installations, but a pipeline count is not a production plan. Split forecasts by readiness level. A project awaiting a survey is different from one with released materials and a confirmed installation window. A project waiting on a utility or authority is not the same as one ready for crew assignment. This distinction lets the company see risk before it arrives at the calendar.

Plan crews with allowances for travel, site variation, training, safety preparation, callbacks, inspections, weather where relevant, and coordination. Do not assume that a nominal crew-day capacity will be reproduced across every project type. Use actual completed work and documented conditions to improve the plan over time, while avoiding unsupported public claims about productivity.

Coordinate sales intake with delivery capacity. If a particular region, roof type, equipment family, or permitting jurisdiction is becoming a constraint, sales leadership should know before customers receive firm expectations. Growth is healthier when the business can say which work it is ready to accept and which work needs a different timeline or specialist review.

Preserve safety and field quality as volume rises

Installation volume must never turn safety preparation into a disposable activity. Solar work can involve fall hazards, electrical hazards, lifting, site access, and changing conditions. OSHA’s public solar safety resources provide general reference material; employers must identify and meet the rules, training, supervision, and procedures that apply to their work.

Maintain site-specific planning, competent supervision, required protective measures, equipment checks, and stop-work authority. A worker who identifies an unsafe condition should have a clear escalation path without being pressured to protect a schedule. High-performing operations treat a stop, correction, and documented restart as a controlled process rather than a personal failure.

Field quality is also information quality. Installation packets should make clear what is current, what has been approved, where required details are found, and which questions must be escalated. Closeout should capture the information the next party needs, such as as-built changes, serial records where applicable, customer documents, inspection results, and service notes. The exact list should reflect the project and jurisdiction.

See connected solar project delivery

Book a SurgePV demo to explore how teams can keep designs, assumptions, and proposals connected.

Book a Demo

Use operating reviews to learn, not to assign blame

At a regular cadence, review a small set of projects that moved well and a small set that did not. Look for failure patterns in the system: incomplete discovery, repeated survey gaps, unclear design status, late customer changes, material mismatch, unclear owner, or misunderstanding of a local process. Ask what upstream control would make the correct action easier next time.

Keep the review evidence-based. A project delay may have multiple causes. Record what is known, what is inferred, and what requires further investigation. Do not manufacture a performance statistic from a handful of examples. The National Renewable Energy Laboratory’s solar market research can provide broad context, but it cannot diagnose an individual company’s workflow.

Turn improvements into operating artifacts: revised intake questions, a clearer design status, a changed approval rule, a training example, or a new exception category. Tell people what changed and why. A process update that lives only in a manager’s head is quickly lost during hiring and turnover.

Introduce systems in the order people can absorb

It is tempting to implement a large software stack and a lengthy manual at the same time. That can add confusion to an already busy organization. Start with the information that causes the most costly ambiguity: project identity, stage, owner, design version, customer decisions, open issues, and the next action. Then build the templates and automation that make those fields easier to maintain.

Train against real, anonymized examples. Show a complete package, an incomplete package, a legitimate exception, and a change request. Give each role a way to ask questions about the process. Audit a few projects soon after adoption and adjust unclear rules. Scaling is an iterative management practice, not a one-time implementation.

Use tools because they support the workflow, not because a dashboard looks impressive. A solar design platform can provide valuable continuity from early concept to customer presentation. The company remains responsible for data quality, professional review, customer commitments, and compliance with applicable requirements.

Conclusion

The move from 10 to 50 solar installations per month is a move from informal coordination to an explicit, learning delivery system. Define stages and readiness, assign decisions to competent owners, control design releases and changes, plan from actual readiness, and preserve safety and quality gates. These practices do not remove site complexity. They make it possible to manage that complexity without losing the customer or the crew in the process.

Explore SurgePV with your operations team

See a connected way to manage solar project information from design to proposal.

Book a Demo

Frequently Asked Questions

What breaks first when a solar company grows quickly?

The first weak point varies, but incomplete handoffs, unclear ownership, untracked changes, and planning based on unready work are common. Map the actual flow before assuming that field labor is the only constraint.

How should a company define an installation-ready project?

Use a documented, local process that identifies the approved design version, needed approvals, materials, customer access, safety planning, and unresolved issues. The exact criteria should match the company’s project type and jurisdiction.

Does scaling require more software?

Not automatically. A company first needs clear operating rules and reliable information. Software can help preserve versions, ownership, and visibility when it supports those rules.

Can a sales team promise a firm installation date at contract signing?

Only when the business has verified the dependencies needed to make that commitment. Many projects still depend on surveys, design review, customer information, authorities, materials, and utility processes.

About the Contributors

Author
Rainer Neumann
Rainer Neumann

Content Head · SurgePV

Rainer Neumann is Content Head at SurgePV and a solar PV engineer with 10+ years of experience designing commercial and utility-scale systems across Europe and MENA. He has delivered 500+ installations, tested 15+ solar design software platforms firsthand, and specialises in shading analysis, string sizing, and international electrical code compliance.

Get Solar Design Tips in Your Inbox

Join 2,000+ solar professionals. One email per week - no spam.

No spam · Unsubscribe anytime

Book Free Demo