RoofGrid: The Solar Layout That Looked Perfect Until We Added a Staircase
Building a rooftop solar planner taught us that finding space for solar panels is easy. Finding space for solar panels that someone can actually install, access, and maintain is a different problem.
Student
The rooftop looked perfect. The layout wasn't.
Imagine a rooftop with enough space for 40 solar panels.
The software draws 40 neat rectangles, calculates the total capacity, estimates the electricity savings, and presents a promising return on investment.
Everything looks good.
Now add a staircase.
Suddenly, a few panels are blocking the entrance. Move them out of the way, and the maintenance route gets blocked instead. Shift the route, and another row of panels no longer fits.
The roof hasn't changed size. The sunlight hasn't changed. The panels haven't changed.
Yet the number of panels we can realistically install has changed.
That distinction became the central problem behind RoofGrid.
When we started exploring rooftop solar planning, the obvious approach was to calculate the available roof area, divide it by the area of a solar panel, and estimate the installation capacity.
Mathematically, it makes sense.
Physically, it can be completely wrong.
A rooftop is not an empty rectangle. It has water tanks, ventilation systems, irregular boundaries, access points, and people who will eventually need to walk around the installation.
So we started asking a different question.
What if the goal shouldn't be to fit the maximum number of panels, but to find the maximum number of panels that can actually work?
That question turned RoofGrid from a solar calculator into a geometry and planning problem.
Part one: A roof is not just an area
Consider two rooftops, both measuring 200 square metres.
One is a clean rectangle.
The other is L-shaped, with a water tank, ventilation equipment, and a staircase near the middle.
A conventional area-based calculator might suggest almost identical solar capacities for both.
But try placing actual rectangular panels on those two rooftops, and you'll get very different results.
That was the first important design decision we made.
We would not calculate panel count from area alone. We would try to place the panels.
RoofGrid starts with a real location.
A user searches for an address, explores the property through satellite imagery, and identifies the rooftop they want to analyse.
We built the mapping experience using Leaflet, satellite imagery from Esri World Imagery, and geographic data from OpenStreetMap.
Building footprint information provides an initial rooftop outline where available.
For the AWS-assisted detection workflow, we also integrated Amazon SageMaker AI to help identify rooftop boundaries from imagery.
But automatic detection introduced another important question.
What happens when the boundary is wrong?
Satellite imagery is not a perfect representation of a building. Roof edges can be obscured by shadows, neighbouring structures can overlap visually, and public building footprints can be incomplete or misaligned.
A boundary that is off by even a small distance can change whether an entire row of panels fits.
Instead of treating an automated prediction as final, we designed RoofGrid so users can inspect the outline and draw or correct it manually.
For irregular rooftops, they can create complex polygons directly on the map.
The important principle is that automation should reduce the work required from the user, not remove their ability to correct the result.
Once the boundary is confirmed, RoofGrid finally knows what space it is working with.
But it still doesn't know how much of that space is usable.
Part two: The staircase changed the problem
This became the most interesting engineering challenge in RoofGrid.
After the user confirms the rooftop, we ask them to mark the actual entry point.
That could be a staircase, ladder, or roof hatch.
Then they identify obstacles: water tanks, skylights, vents, AC units, or other structures that panels must avoid.
Why does the entry point matter?
Because a maintenance path that doesn't connect to the place where someone enters the rooftop is not particularly useful.
We needed the application to understand connectivity, not just empty space.
This turned the rooftop into a graph problem.
First, we transform the geographic roof polygon into a local coordinate system measured in metres. Working in metres lets us reason about actual panel dimensions, spacing, and walkway widths rather than raw latitude and longitude.
Next, we construct a grid representing navigable rooftop space.
Each grid cell is classified according to whether it falls inside the rooftop and outside obstacles.
Starting from the user's selected entry point, we use a breadth-first-search-based connectivity model to find reachable regions and construct connected maintenance paths.
Those paths are then buffered into physical exclusion zones.
That last step matters.
A walkway cannot just be a thin line drawn between panels. It needs actual width.
So the space reserved for access becomes space that panels are not allowed to occupy.
The result is a rooftop model that understands three different things:
- Where panels could physically fit.
- Where people need to move.
- Which placements would interfere with those movements.
Only after those constraints are accounted for do we generate the panel layout.
This also gives RoofGrid an interesting property.
Move a water tank, and the accessible space can change.
Move the staircase entry point, and the maintenance network can change.
Change the maintenance clearance, and the number of feasible panels can change.
A roof's solar potential is not a fixed property of its area. It depends on the constraints under which the roof must operate.
Part three: Actually placing the panels
Once we had a usable rooftop polygon, we needed to solve the next problem.
Where should the panels go?
The simplest approach would be to generate a rectangular grid of solar panels and discard anything outside the roof.
But that can waste significant space.
Imagine a long rooftop rotated 20 degrees relative to north.
A panel grid aligned in the wrong direction may leave awkward triangular gaps along the roof edges.
Rotate the same grid to follow the building, and another row might fit.
So RoofGrid evaluates multiple candidate orientations.
We use Turf.js and our spatial calculations to examine the roof geometry, including its longer edges, and generate possible panel-grid rotations.
For each candidate orientation, RoofGrid places panels with the required spacing and checks whether the panel corners fall inside the rooftop polygon.
Then it checks the exclusion constraints.
A proposed panel is rejected if it intersects an obstacle, overlaps a maintenance walkway, or violates the configured service-access rules.
We also test multiple grid offsets.
This sounds like a small detail, but shifting an entire layout by a fraction of a panel width can change how many panels fit near an irregular boundary.
Conceptually, the search looks like this:
Plain text
For each candidate orientation:For each candidate grid offset:Generate possible panel positionsFor each panel:Check rooftop boundaryCheck obstacle intersectionsCheck maintenance pathwaysCheck service accessibilityKeep only valid panelsCompare valid layoutsReturn the best feasible layout
The goal is not to produce the largest number of rectangles on a satellite image.
The goal is to produce a feasible arrangement under the geometric and access constraints represented in the planner.
That also meant confronting performance.
Testing many panel candidates against complex polygons can become expensive, particularly for larger rooftops.
We introduced optimizations including caching, limits on layout searches, and simplified visualization for large panel arrays.
There is a useful distinction here: the number of calculations required to choose a layout and the number of objects that need to be individually rendered are not necessarily the same.
Separating the two helped us preserve an interactive experience.
Part four: A technically feasible layout can still be a bad investment
At this point, we could answer a physical question.
How many panels can fit?
But a homeowner considering rooftop solar is not really trying to buy the maximum number of panels.
They are trying to understand whether installing solar makes sense.
A system that generates plenty of electricity but costs too much to recover its investment may not be attractive.
Similarly, two identical solar systems in different locations can produce different amounts of energy.
So RoofGrid needed to connect the physical rooftop layout to the economics of the actual location.
We integrated the NASA POWER API to retrieve location-specific solar and temperature data.
Rather than treating sunlight as constant throughout the year, RoofGrid models monthly solar production using local irradiation and temperature information.
The estimate takes into account system capacity and assumptions such as panel efficiency, orientation, tilt, temperature losses, soiling, shading allowances, and system losses.
The result is not just one impressive annual electricity number.
It is a monthly energy-generation profile that reflects seasonal variation.
Then we connect energy production to financial outcomes.
RoofGrid estimates installation cost, electricity-bill savings, payback period, return on investment, net present value, internal rate of return, and levelized cost of energy.
The lifetime financial model also considers factors such as degradation, maintenance, inflation, and inverter replacement.
But there was another trap here.
A precise-looking number is not necessarily an accurate number.
Electricity prices vary across cities. Export compensation depends on local policies. Installation costs depend on the market, hardware, and the property itself.
A financial model can calculate an answer to two decimal places while relying on completely inappropriate assumptions.
Instead of hiding those assumptions, RoofGrid exposes them.
Users can edit electricity tariffs, installation costs, annual consumption, self-consumption rates, and other key inputs.
We wanted users to understand not only what the estimated payback period is, but what makes it change.
That is also why RoofGrid should be understood as an early-stage planning tool, not an engineering certification or a guaranteed financial forecast.
A useful estimate should help someone ask better questions before committing money.
It shouldn't pretend uncertainty has disappeared.
Part five: Giving the numbers an explanation
At this stage, RoofGrid could generate rooftop layouts, estimate energy production, and calculate financial outcomes.
But there was still a usability problem.
A user might see a payback period of several years without understanding why.
They might see fewer panels than expected and wonder whether the algorithm made a mistake.
Or they might want to know what happens if electricity prices rise.
This is where we wanted AI to become more than an unrelated chatbot added to the interface.
We built RoofGrid AI around the actual analysis context.
The assistant receives information about the current rooftop calculation, such as roof area, system capacity, estimated generation, installation cost, savings, and payback period.
This allows the user to ask questions about their specific result.
For example:
"Why does this rooftop have fewer panels than I expected?"
"What happens to my savings if electricity prices increase?"
"How is the payback period calculated?"
The underlying numerical and geometric work remains separate from the conversational explanation.
That distinction is important.
The AI should help users interpret the analysis. It should not invent roof measurements, silently change assumptions, or replace deterministic geometry checks with conversational guesses.
For the AWS deployment, we integrated Amazon Bedrock to provide AI capabilities through a managed cloud service, while keeping credentials and backend execution away from the browser.
The principle was simple:
Let the calculations establish the facts. Let AI help users understand them.
Part six: Taking RoofGrid onto AWS
Building an interactive planner is one problem.
Running its backend reliably, keeping credentials secure, and making the service accessible to users is another.
For our AWS deployment, we used a serverless architecture so that the application could respond to requests without requiring us to manage a continuously running application server.
The frontend is deployed through AWS Amplify Hosting.
For backend operations, Amazon API Gateway provides the HTTP interface to AWS Lambda functions.
The Lambda layer handles server-side operations, including the AI integration.
Amazon Bedrock supplies the managed AI capability, while Amazon DynamoDB supports backend persistence and usage-related state.
AWS Secrets Manager protects sensitive configuration, and IAM policies define which AWS resources each component can access.
CloudWatch provides visibility into operational behaviour and errors.
We also used AWS SAM and CloudFormation to define and manage the cloud deployment.
The important part of this architecture is not the number of AWS service names.
It is the separation of responsibilities.
A browser should not contain a private model credential.
A rooftop-layout calculation should not depend on an AI response to decide whether a panel intersects a water tank.
A request to explain financial results should not need to recompute every geometric operation.
And the application should not require us to keep a dedicated server running while nobody is using it.
By keeping the spatial planning engine responsive in the browser and placing the appropriate backend responsibilities on AWS, we could keep the user experience interactive while supporting secure cloud-powered functionality.
Part seven: The problems that were harder than expected
RoofGrid brought together several technologies that solve very different classes of problems.
And the difficult parts tended to appear where those systems met.
1. Real-world building data is not clean
A building footprint may be missing, inaccurate, or inconsistent with the satellite image.
For our early-stage planner, rejecting an entire rooftop because automatic detection was uncertain would make the tool less useful.
So manual polygon drawing and correction became essential parts of the product rather than fallback features hidden away from users.
2. Geometrically valid is not operationally useful
A panel can be completely inside a roof polygon while still blocking maintenance access.
This was the reason we added an entry-aware pathway model instead of simply subtracting an arbitrary percentage of area.
3. More computation does not automatically mean a better experience
Evaluating candidate rotations, offsets, and intersection constraints is useful, but searching too many possibilities can slow down the interface.
We needed to balance search quality with responsiveness and avoid drawing thousands of individually interactive objects when a simplified visualization could communicate the result.
4. External services can fail independently
RoofGrid combines mapping data, geographic search, solar information, and AI services.
These dependencies have different failure modes.
A building lookup returning no useful footprint is not the same as a failed solar-data request.
An unavailable AI response should not erase an otherwise valid roof layout.
Designing alternative user flows, request validation, caching, and server-side isolation became important to keeping the application useful when an external integration was unavailable.
5. Environmental and financial numbers need context
A solar installation can avoid grid electricity consumption, but the estimated emissions benefit depends on the grid-emissions factor used.
Similarly, financial savings depend on tariff and self-consumption assumptions.
We made those inputs visible because a model is easier to trust when the user can inspect its assumptions rather than simply accepting a final number.
Part eight: What RoofGrid can do today
RoofGrid now connects a set of tasks that are often handled separately.
A user can locate a real rooftop, confirm its boundary, define obstacles, mark the entry point, generate access-aware solar panel layouts, estimate monthly electricity generation, inspect long-term financial outcomes, ask questions about the results, and export a PDF planning report.
The most important part is that these are connected steps.
The rooftop geometry influences panel placement.
Panel placement determines installed capacity.
Installed capacity influences energy generation.
Energy generation, together with user-defined assumptions, influences financial and environmental outcomes.
A change near the beginning of the workflow can affect the final decision.
That's what makes RoofGrid more than a calculator with a satellite map.
It is an attempt to connect the physical reality of a rooftop to the decisions someone needs to make about solar installation.
There are still limits.
RoofGrid does not yet replace structural analysis, detailed 3D shade simulation, electrical design, local permitting checks, or an installer’s site survey.
Those are important steps before a real installation.
Our aim is to help users arrive at those conversations with a more informed starting point.
Three things I would tell myself before building RoofGrid
First: draw the constraints before optimizing the result.
If we had focused only on maximizing panel count, we could have produced visually impressive layouts that were operationally useless.
The staircase, obstacles, and maintenance routes are not secondary details. They define the planning problem.
Second: let automation propose, but let people verify.
Real-world geographic data is imperfect. AI-assisted detection can make the process faster, but users still need the ability to correct the boundaries and assumptions on which every subsequent calculation depends.
Third: the explanation matters almost as much as the answer.
A user does not necessarily benefit from knowing that 36 panels fit on a rooftop.
They benefit from understanding why 36 fit, why more were rejected, what those 36 panels might generate, and which assumptions influence the predicted savings.
A trustworthy planning tool should make its reasoning inspectable.
The question we're still trying to answer
When we started thinking about rooftop solar software, the question seemed straightforward.
How many panels can fit on this building?
After working through roof geometry, access paths, solar data, financial models, and cloud infrastructure, that question feels incomplete.
A better question is:
How much solar can this rooftop support without ignoring what makes the rooftop usable in the first place?
And even that is only the beginning.
The next steps for RoofGrid include better roof-plane and elevation data, 3D shading, structural considerations, configurable safety setbacks, battery-storage modeling, and more detailed installer handoff workflows.
The long-term goal is not to eliminate the need for solar professionals.
It is to make the first conversation with one much more informed.
Because the best solar layout isn't necessarily the one with the most panels.
It's the one that still makes sense when somebody actually has to build it.
Built with: Amazon SageMaker AI, Amazon Bedrock, AWS Amplify Hosting, Amazon API Gateway, AWS Lambda, Amazon DynamoDB, AWS Secrets Manager, AWS IAM, Amazon CloudWatch, AWS SAM, AWS CloudFormation, Leaflet, Turf.js, OpenStreetMap, Esri World Imagery, NASA POWER API, JavaScript, and Python.
Built by the RoofGrid team — Rohan Malhotra and Dyaus Ghangas.
RoofGrid is an early-stage planning and decision-support tool. Its estimates are not a substitute for a professional installation survey or engineering assessment.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article