A Conditions Builder

Background

Adders for a solar system are anything that adds cost to a job beyond the base panel-and-inverter system. A good analogy is buying a car. The base price gets you the vehicle, but then you add heated seats, a tow package, an extended warranty. The solar system is the base; adders are everything a specific job requires on top of that. They exist because every house is different, and a flat price-per-watt can’t account for all the variables that affect what a job actually costs to install.

---

Problem

In Aurora, adders exist as flexible database objects used to account for additional project costs. An admin would create a steep roof adder intended to be applied every time a house had a steep roof. However, the only way to ensure these adders were applied was through training.

A manager inside a solar installation company would explain to reps that in the case of a roof with a steep incline, something like over 40 degrees, they would need to apply a steep roof adder to account for things like extra equipment, safety gear, and additional required training.

This is really hard to enforce, especially for a scaling organization. Two main problems emerged:

Inconsistency & sloweness

• ❌Project costs varied from job to job; reps would forget to apply extra costs across all the relevant conditions
• ❌Ensuring costs were accurate across all conditions was taking too long and impacting time-to-close

---

Goals

Together with my product manager, we compiled a set of goals for this project:

• 🎯Reduce the time it takes to price a system
• 🎯Prevent human error and protect against proposals that don't conform with business goals
• 🎯Ensure consistency across projects
• 🎯Build a framework that's scalable

---

Research and workshop

I felt I had a strong handle on the “why” behind this initiative based on what we were hearing from customer calls, but the specifics eluded me. To get a better handle on what customers were actually requesting, I dug into our customer insight tool, our production environment, and some existing adder reporting.

A consistent set of conditional themes started to emerge. Customers needed to add extra charges under these conditions, among others:

• Apply always – an adder applied to every project that moves through the system; a “summer surcharge,” for example, might account for an influx of projects during a specific time of year
• Components (modules, inverters) – some components are considered premium models; they perform better but cost more
• System size – the ability to incorporate economy-of-scale logic; larger systems charge less per watt installed than smaller ones
• Roof pitch: – pricing a system differently depending on how steep the roof is, accounting for extra equipment, safety gear, and additional required training
• Location or utility: – a project in one region or utility territory might cost more than one in another; ground mount installs in northern Oregon may require less excavation effort than those in rockier southern terrain, each demanding different equipment and time

After distilling common conditions from across our customer base, my product manager and I ran a workshop with the team to iterate on solutions. We had an onsite planned and were able to run the session in person, which helped build alignment on why the problem mattered, surfaced technical expertise early, and let us move quickly.

---

Framework

The workshop generated a range of ideas and the team aligned on a conditions builder concept. My role afterward was to make that idea a reality.

I researched HubSpot, Salesforce, and others, for inspiration on how to solve this type of problem. I landed on a separate section that attaches to the bottom of the adder page in the database, making conditions a property of the adder object itself.

“Apply to all designs” was split out as a separate selection, since it’s untethered to specific project conditions. Because adders were already a feature that could be manually toggled on and off, the new functionality couldn’t replace that. It needed to sit alongside it.

I then worked out how users would select a condition to determine applicability. This required an object type dropdown allowing users to select from properties of a design, an operator input to define the relationship between the object and the design, and a way to target the specific object itself, for example, a particular module SKU.

Condition builders can look technical and intimidating, so to give users confidence they’re setting up the right rules, I added a plain-language summary that communicates the behavior of each condition.

To pressure-test the design, I layered in our different condition use cases. This was invaluable for understanding how each operator and object selection needed to adapt across different object types. It was also during this exercise that my product manager and I introduced a sense of prioritization, evaluating the frequency of requests per condition type alongside implementation complexity.

---

Research

To validate the designs, we booked feedback sessions with four customers who most frequently used adders in their projects. I built a simple prototype, developed a script centered on our key talking points, and ran the sessions.

On the whole, the designs and our prioritization of conditions were well received. One finding stood out: opinions were split on what should happen to the adder toggle once automatic applicability kicked in. Some customers expected it to stay active; others felt it should be disabled since the adder was being applied automatically.

My product manager and I made the call to disable it, siding with a customer who put it plainly: being able to manually shut off an automatic adder would “kinda defeat the purpose.”

---

“Wait, what happens when there’s a change in the database?!”

One of the more complex problems surfaced during a pod design review was figuring out what should happen when an admin changes a database object that’s already being used downstream.

After brainstorming with engineering about technical constraints, I built a document mapping out multiple scenarios, all aimed at answering the same question: when does an adder or discount reflect a change made in the database? This covered changing the condition type, changing the condition criteria, creating a new condition, and deleting a condition. I then mapped out at which points in the flow the adder objects would refresh and inherit those changes.

Because these changes automatically affect the price of a solar system, getting it wrong means inaccurate costs communicated to a homeowner and a potential sale lost. High-stakes.

---

States

The next step was ensuring other product areas were accounted for. How do these adders appear on the pricing page, for example? I documented these pages and state changes as part of the design specs.

---

Results

We released in Q3 2023 with support for modules, inverters, roof pitch, and system size, followed by array count, ground mount, storage operating mode, and others. Because of the scalable framework, subsequent conditions shipped significantly faster.

“Before Aurora, our price adjustment process was labor-intensive, relying on custom equations. With Aurora Solar, we’ve shifted to a rapid, automated system, allowing us to calculate price changes in less than a minute. This has not only saved us significant time but also minimized human errors, making our process at least five times faster.”

— Orizon Energy

---

Learnings

• A flexible solution (in this case adders) can shed light on new feature potential.
• Use a range of different use cases to pressure-test a design; it makes the solution more robust and future-proof.
• For complicated features, thorough documentation is your friend.