An ops platform where the building is the record, not the deal
CRM, site records, surveys, quotes, consents and delivery in one system, where a deal covers as many buildings as the negotiation does, and winning it opens one project per building.
- project per building, on winning
- 1
- destinations regrouped, none dropped
- 30
The problem
Solar is sold to a company and installed on a building, and the two do not map one to one. A rollout across six depots is one negotiation, one decision and one forecast, but six roofs, six grid connections and six surveys. The platform allowed one site per deal, so the team either raised six deals for a negotiation that happened once, or recorded one and left five buildings off the system.
Grid, planning and structural applications inherited the same problem. They were filed against a deal rather than a building, so on a multi-site deal there was no reliable answer to which roof an application was for, and the historic records could not tell anyone after the fact.
Getting to a building was slow in its own right. The sidebar was twenty unlabelled siblings, and a site's address, supply detail, surveys, deals and consents sat on screens that did not reference each other.
What we built
The building is the record
A deal now covers as many buildings as the negotiation does, with one marked primary, and each site shows every deal covering it. The quote stays per deal (one negotiation, one quote) but it names the buildings it prices, and a multi-building quote states what winning it will do. Nothing about how a sale is run changed. What changed is the number of roofs a single sale is allowed to describe.
One project per building, and money that adds up
Winning a deal opens one project per building, each named for its building, each with its own delivery board, tasks, milestones and procurement starters. Contract value splits across the buildings in scope with the remainder landing on the primary, and a test pins that the parts always sum back to the contract exactly. Milestones are struck as percentages of those figures. Re-running a win is safe: a building linked after the win gets its project on the next run, with nothing duplicated.
Consents that cannot leak
Grid, planning and structural applications are scoped to the building they belong to, and project adoption is scoped to each project's own building. Without that second scope, whichever project was created first would swallow the other five buildings' applications, which reads as working software right up to the point somebody checks which roof an application is for.
A migration that refuses to guess
Historic consents recorded only their deal. The migration filed them against a building only where the answer is unambiguous, meaning the deal covers exactly one site. Deals covering several were deliberately left alone: which of six depots a grid application belongs to is not something a migration can know, and a guess puts an application on the wrong roof. Those records surface in a panel on the site that explains how to file them.
Seven tabs, and four headings above them
The site record is seven tabs: a data-readiness overview naming what is missing and which stage it blocks, then location and access, meter and supply, surveys, deals and quotes, grid and planning, and the customer. The current tab lives in the URL, so it survives a refresh and can be linked to. In the sidebar, twenty unlabelled siblings became four headings, with leads, companies, contacts, sites and opportunities grouped under customers in the order a sale moves through them. All thirty destinations were kept. Capturing a lead now opens an opportunity and links the company and contact, so the leads board is a view over early-stage deals rather than a table of its own.
The outcome
A rollout across six depots is one deal, one quote and one forecast, and six projects, each named for its building, each with its own delivery board and milestones, and each holding a share of the contract value that a test keeps summing back to the total. Grid and planning applications sit on the roof they belong to.
Four failures that had been quiet were found and fixed on the way: a deal page whose query dropped every consent filed against the site while appearing to merge them, a migration with no twin for the deployed database so production would never have received the table, a documented column no route could write and nothing rendered, and a sandbox fallback that changed a deal's primary site every time a building was added.
The backfill filed nothing it could not prove, and that limit is visible rather than hidden. Historic consents on deals covering more than one site are still unfiled, listed in a panel on the site record with an explanation of how to file them, because the alternative is a grid application sitting on the wrong roof and nobody knowing.
Built with
- Next.js
- TypeScript
- Supabase
- PostgreSQL
- REST
Where this is applied
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no