How Solar Companies Can Scale From 10 to 50 Projects a Month Without Chaos

Scaling from 10 to 50 solar projects a month is not a matter of doing the same work five times faster.

At lower volume, an owner or operations lead can often hold missing context in their head. They know which permit is stuck, which crew needs a material change, which customer is waiting, and which invoice should go out next.

As volume grows, that memory stops being a control system. More projects create more simultaneous survey, design, permit, utility, procurement, scheduling, field, inspection, PTO, and billing decisions.

The practical answer is to change the operating model before the company reaches each new volume band: standardize the work at lower volume, manage queues at mid-volume, and systemize capacity, ownership, and financial control as throughput grows.

What actually changes when a solar company goes from 10 to 50 projects a month?

The biggest change is not the number of projects. It is the number of things that can be waiting at the same time.

One sold job may be waiting on survey data. Another is in design. Five are with different AHJs. Two need utility follow-up. One is ready to install but missing an inverter. Three are installed but not through PTO. Another has a completed billing milestone that finance has not reviewed.

At 10 projects a month, the team may coordinate those exceptions through direct conversation. At 30, the business needs consistent stage definitions, queue ownership, and capacity visibility. At 50, the same company usually needs repeatable controls that do not depend on one coordinator remembering the whole portfolio.

The 10, 30, and 50 project bands in this guide are operating examples, not industry thresholds. A standardized residential installer can handle a different volume than a commercial EPC with longer engineering, procurement, and utility cycles.

Monthly project volume can hide your real operating load

“30 projects a month” sounds like 30 things to manage. In reality, monthly starts and active work in progress are different numbers.

A simple planning approximation is: active work in progress ≈ monthly project starts × average project lifecycle in months.

If a company starts an illustrative 30 projects per month and the average project remains active for three months from project creation through closeout, roughly 90 projects can be in the operating system at the same time.

That does not mean every one of those 90 projects needs equal attention. It means the company may simultaneously carry 90 customer records, project states, permit or utility dependencies, material decisions, field commitments, documents, costs, and financial events.

This is why companies often feel as if growth suddenly became chaotic even though sales volume increased gradually. The operating load compounds because each month's new work lands on top of work that has not yet exited the system.

Track work in progress by stage, not only total jobs

One total active-project count is not enough for scaling decisions. Break work in progress into the operating queues that actually consume capacity.

That can include survey waiting, design in progress, engineering review, permit submitted, permit correction, interconnection or utility action, procurement, material readiness, ready to install, inspection, PTO, billing, and closeout.

The exact stages depend on the business. The important part is knowing where work is accumulating faster than it leaves.

Around 10 projects a month: standardize while communication is still cheap

At lower volume, direct communication is an advantage. The owner can talk to the salesperson, designer, permit coordinator, crew lead, and bookkeeper without building a complex management layer.

Do not throw away that speed. Use it to document the small set of rules that future employees should not have to rediscover.

Start with the moments where one team hands responsibility to another. What must sales provide before design accepts the project? What makes a permit packet ready? What conditions must be true before a crew is scheduled? What evidence makes an installation or billing milestone complete?

The goal at this stage is not heavy process. It is to turn tribal knowledge into simple operating rules while the team can still see the whole workflow.

Five controls worth establishing early

Every live project should have a current stage, one accountable next owner, one next action, the evidence required to move forward, and a clear rule for when the stage is complete.

Those five controls make growth easier because the next employee does not need to learn the business entirely through Slack, WhatsApp, inbox searches, or sitting beside the owner.

They also create the data needed later. You cannot measure permit aging, install readiness, or queue capacity at 30 or 50 projects a month if the company never defined those states at 10.

Around 30 projects a month: stop managing jobs and start managing queues

Mid-volume operations often feel busy everywhere. That makes it tempting to solve every problem with another hire.

First ask a different question: which stage is receiving work faster than it can complete it?

Use a simple flow equation: backlog change = work entering a stage - work completing the stage.

Suppose design receives an illustrative 30 projects in a month but completes 22. The design backlog grows by eight projects. If the same gap repeats next month, the problem compounds even if every designer appears fully occupied.

Now leadership has a better question than “Why is design slow?” It can examine whether the constraint is actual design capacity, incomplete survey inputs, rework, approval delay, equipment changes, or too much variation in the work entering the queue.

Separate internal work from external waiting

Permit and interconnection queues make this especially important. A project waiting on an AHJ or utility is not the same as a project where the outside party already responded and the team has not taken the next action.

The Department of Energy notes that local permitting and inspection requirements vary and that administrative errors and backlogs can create delays. Growing installers therefore need to distinguish external aging from internal aging rather than treating every permit-stage day as the same problem.

At this volume, the owner should be able to see how much work is waiting, how old it is, why it is waiting, and which team can actually change the outcome.

Around 50 projects a month: systemize decisions, not just tasks

At higher monthly throughput, the problem changes again. The company is no longer only coordinating projects. It is coordinating functions that each have their own queue, capacity, standards, and financial consequences.

Design can be healthy while permitting is overloaded. Permitting can be healthy while material readiness is weak. Crews can have open capacity while too few projects are truly install-ready. Install volume can rise while closeout and billing quietly accumulate behind it.

A task board alone cannot answer those tradeoffs. Leadership needs a management system that connects project flow with capacity, materials, workforce, cost, and cash.

The objective is not to make every action identical. Solar work still contains AHJ differences, utility exceptions, site conditions, customer changes, equipment substitutions, and technical judgment. Systemization means the predictable part of the work follows defined rules so the team can spend attention on exceptions.

Create process owners before every problem becomes an owner problem

A useful change at scale is separating project ownership from process ownership.

The project owner is accountable for the specific job reaching its next milestones. The process owner is accountable for whether a function such as design, permitting, procurement, field readiness, or closeout works consistently across the portfolio.

This distinction prevents the owner from personally becoming the escalation point for every project. It also turns repeated exceptions into process improvement instead of a permanent stream of firefighting.

Which operating queues usually reveal the scaling problem first?

There is no universal order. The first constraint depends on what the company sells, how standardized its work is, which jurisdictions and utilities it serves, whether it stocks material, and how much work is performed in-house.

Still, five queue types deserve close attention because they connect several teams and can expose downstream commitments.

Survey and design

A fast sales month can create a design backlog several weeks later. Measure whether incoming projects are complete enough to design, how many are returned for missing information, and whether revisions are consuming capacity that should have gone to new work.

The important scaling question is not simply how many designs a person finishes. It is how cleanly work enters the queue and how much capacity is consumed by preventable returns.

Permitting and interconnection

These queues combine internal work with external dependencies. Track submissions, corrections, internal response time, external aging, inspection dependencies, utility actions, and PTO follow-up separately enough that the team knows which delays it can control.

A growing total is not automatically a staffing signal. The reason behind the growth matters.

Procurement and material readiness

More installs create more opportunities for the right equipment to exist somewhere in the company but not be reserved, approved, or available for the correct project.

At scale, procurement needs to know not only what was ordered, but which project needs it, whether the approved design matches it, when it is expected, where it is, and whether the project can still meet the scheduled field commitment.

Crew scheduling and install readiness

Adding another crew does not increase output if the company cannot feed that crew ready work.

Measure the ready-to-install queue separately from the scheduled-install queue. A job with a calendar date can still be blocked by permit conditions, material, customer access, an outdated plan set, subcontract work, or another prerequisite.

The scaling question becomes: do we need more crew capacity, or do we need more projects that can actually use the capacity we already have?

Billing, PTO, and closeout

Growth can look healthy on an install count while cash and completion work accumulate behind the field team.

Track installed-but-not-inspection-ready, inspection-complete-but-PTO-pending, invoice-ready-but-not-issued, open punch items, and other closeout conditions that matter to the company's contracts and operating model.

The Department of Energy includes administrative work, permitting, interconnection, supply-chain and inventory control, and operating overhead among solar soft costs. These are not side issues. They are part of what determines whether more sold projects become more completed, billable projects.

Before hiring, measure arrivals, completions, work in progress, and age

Headcount decisions are easier when the company measures flow instead of relying on how busy the team feels.

For each important operating queue, track four basic numbers over time: arrivals into the queue, completions out of the queue, total work in progress, and the age of the oldest and typical items.

Then add a fifth measure when useful: how much work is being returned for missing information, corrections, or rework.

Those numbers do not need a sophisticated analytics project. They need stable definitions. Once the company can see them, it can distinguish a true capacity ceiling from a process that is wasting the capacity it already has.

Is this a hiring problem or a workflow problem?

A growing backlog can mean the team needs more people. It can also mean people are spending too much time repairing incomplete work. Use this test before opening a role.

Sometimes the answer really is another designer, permit coordinator, warehouse employee, crew, or finance person. The point is to hire into a defined system with a measurable capacity need rather than adding a person whose main job is to absorb unclear workflow.

What should an owner measure as the company scales?

Do not build a giant KPI library just because more data is available. For scale, the owner mainly needs to see whether volume is creating a capacity or control problem.

A practical scale view can include monthly project starts and completions, work in progress by major stage, queue aging, arrival-versus-completion trend at the bottleneck, install-ready work versus available crew capacity, recurring rework or return reasons, and operational events affecting cash or margin.

This is not the same as a project-status board. The purpose is not to read every job. It is to see whether the operating system can absorb the next increase in volume.

Watch ratios and trends, not magic thresholds

An installer does not become mature because it has exactly 30 projects a month. The useful question is whether the process remains stable as volume changes.

If arrivals rise 20% and backlog rises 60%, something is losing capacity or quality. If project starts increase while completion volume stays flat, work is accumulating somewhere. If install volume grows but invoice-ready aging also grows, field throughput is outrunning financial closeout.

Your own baseline is more useful than copying another company's project-per-coordinator or jobs-per-crew benchmark.

When does ERP become necessary for a growing solar company?

There is no single project count where ERP suddenly becomes mandatory.

ERP becomes increasingly valuable when several parts of the business must keep the same project, material, workforce, cost, customer, and financial state synchronized, and manual coordination is becoming a management risk.

That usually becomes visible through symptoms: the owner cannot see where capacity is constrained, the same project status is maintained in several places, material availability is disconnected from install readiness, field completion does not reliably reach finance, or growth requires another reporting layer just to reconstruct what happened.

A smaller company with complex commercial work may reach that point earlier than a higher-volume company with highly standardized residential jobs.

ERP should remove management joins

Think of a “management join” as a question that requires leadership to combine several systems or people before getting one answer.

Can we install this project next week? The answer may depend on permit status, current design, material allocation, customer or site readiness, crew capacity, and outstanding issues.

Can we bill this milestone? The answer may depend on field evidence, inspection status, contract terms, approvals, and finance rules.

As volume grows, those joins multiply. ERP becomes useful when the operating system can carry those relationships directly instead of asking employees to rebuild them for every decision.

A practical solar operations maturity model

The most useful way to think about 10 to 50 projects a month is not as three hard thresholds. Treat them as maturity checkpoints.

Level 1: Transaction discipline

Customer, project, sold scope, documents, and basic financial records are captured consistently. The company can find the current job and knows which record is authoritative.

Level 2: Workflow discipline

Stages have clear entry and exit rules. Handoffs include required information. Every exception has an owner and next action.

Level 3: Queue control

The company can see work in progress, aging, arrivals, completions, and blocker causes for important functions such as design, permitting, interconnection, material readiness, field work, and closeout.

Level 4: Capacity control

Leadership can compare expected demand with available design, permit, procurement, crew, warehouse, and finance capacity. Hiring and scheduling decisions are based on measured constraints rather than general busyness.

Level 5: Connected financial and service control

Project events connect to purchasing commitments, material use, labor, billing, job cost, cash, installed equipment, and later service or warranty history. Growth no longer ends at “more installs.” The business can see whether more volume is producing healthy delivery and financial outcomes.

A company doing 10 projects a month may already need Level 4 controls if the projects are complex. Another company may operate at 30 with a simpler structure. The maturity model is a way to ask what the business needs next without pretending the project count itself is the answer.

How is Solar1 being designed for this scaling problem?

Solar1 is being built as a complete solar-specific ERP for installers and EPC companies.

Its product direction is to connect sales and customer information with project delivery, design workflow, permitting, interconnection, procurement, inventory, field activity, workforce, finance, PTO, service, warranty, and management reporting so growth does not require a new layer of manual reconciliation at every stage.

For scaling teams, that means the operating system should eventually help answer both project questions and capacity questions. Which jobs are blocked? Which queue is growing? Which projects are ready for field capacity? Which material is committed? Which operational milestone affects billing? Which cost or labor change affects the project forecast?

Solar1 is still under development, so this describes the operating model the product is being designed around. It does not mean every capacity view, workflow, finance control, automation, or service capability described here is currently production-ready.

Scale the operating system before the project count forces you to

The wrong time to define a permit handoff is when 18 corrections are already waiting. The wrong time to decide what “install ready” means is after a crew reaches a job without the right material. The wrong time to define project-cost ownership is after volume has already hidden where margin changed.

Use each increase in project volume as a checkpoint.

Ask whether the next ten projects will create more useful throughput or merely more work in progress. Check the queue that is closest to its limit. Fix missing ownership and rework before adding capacity. Add capacity when clean work is genuinely arriving faster than the team can complete it.

Then repeat the test as the business grows.

Use the Solar Ops Maturity Scorecard to rate transaction discipline, workflow discipline, queue control, capacity control, and connected financial control before the next volume jump.