Solario PV platform

Three apps, one backend

The platform consists of three independent Angular apps sharing a Supabase data layer — mapped onto the classic Solario sales process: online inquiry, home visit, worked-out offer, installation, handover.

Builder — the customer-facing inquiry app, public, no login, conversion-critical. A prospective customer enters their address, sketches their roof segments roughly and describes what they have in mind — no component-level material choices, no detailed technical decisions. Out comes a first, internally consistent inquiry that the Solario consultant can review before the on-site appointment. The app reserves a configuration_id on the first click and uses it as anonymous pseudo-auth — the inquiry is shareable as a link, the data exists in the database from second one.

Configurator — the worked-out offer the customer lands in after the home visit. Here the consultant has filled in the technical details from the on-site appointment (roof access, wiring, shading, meter cabinet); the customer sees concrete module series, concrete inverter, optional components with surcharge, and detailed economic statistics. Materials can be swapped live (premium vs base module), impact on price, yield and payback shows immediately — often the consultant sits with the customer in front of the screen and adjusts it interactively.

Planner — the internal app with Supabase Auth and row-level security per tenant. Consultants see all inquiries from their tenant, schedule the on-site appointments, fill in technical details after the home visit (module series, wiring, which inverter fits which string layout), generate quotes and accompany the customer through installation and commissioning to handover of the finished system. Master-data editing (manufacturers, modules, inverters, subsidies, electricity-price assumptions) happens here too.

All three apps pull their TypeScript types directly from the Supabase schema via GraphQL codegen — a schema change lands in all three frontends, type-safe, within minutes. This was especially valuable in the early phase when the data model and UI requirements were still co-evolving: every few days something changed in the model, and a hand-maintained types layer would have ground us down.

Approach

The central design decision was to not shred the PV system into ten normalised tables, but to keep it as a versioned JSON in a single column. A PV system has irreducible complexity — modules, inverters, batteries, roof segments with shading sections, optional emergency backup, every component with properties that vary by manufacturer. Forcing every relationship into a table would mean every new component type is a migration. Instead:

• The schema lives as a Zod definition in TypeScript and is validated on the app side.
• New fields are added additively — schema_version increments, older versions are migrated on read.
• Postgres indexes on JSON paths (->> and jsonb_path_ops) cover the few queries we actually run across systems (e.g. “all systems with manufacturer X”).

That buys us refactoring freedom without losing data integrity: the schema is versioned, every read goes through validation, and only structurally correct objects are written.

import { z } from 'zod';

export const ModuleEntry = z.object({
  model: z.string(),      // e.g. "JA Solar JAM72S30-545"
  count: z.number().int().positive(),
  power_wp: z.number().positive(),
});

export const SystemV2 = z.object({
  schema_version: z.literal(2),
  modules: z.array(ModuleEntry).min(1),
  inverter: Inverter,
  storage: Storage.optional(),
  roofs: z.array(RoofSegment).min(1),
});

// On read: older versions are migrated here.
export function readSystem(raw: unknown): z.infer<typeof SystemV2> {
  const v = (raw as any)?.schema_version ?? 1;
  return v === 2 ? SystemV2.parse(raw) : migrateV1toV2(raw);
}

Highlights

query GetOffer($id: UUID!) {
  offer(id: $id) {
    id
    status
    customer { name email }
    system {
      modules { model count }
      inverter { model power_kw }
      storage  { model capacity_kwh }
      roofs    { area_m2 azimuth tilt shading }
    }
    pricing { total vat installation_eur }
  }
}

# → generates GetOfferQuery, GetOfferQueryVariables,
#   useGetOfferQuery(), watchGetOffer() automatically.

// V1 had `roof_area_m2` as a scalar. V2 has an array of RoofSegments with
// per-segment orientation — roofs with a south + west section need that for
// an honest yield estimate.
export function migrateV1toV2(raw: unknown): z.infer<typeof SystemV2> {
  const v1 = SystemV1.parse(raw);
  return SystemV2.parse({
    schema_version: 2,
    modules: v1.modules,
    inverter: v1.inverter,
    storage: v1.storage,
    roofs: [{
      area_m2: v1.roof_area_m2,
      azimuth: v1.roof_azimuth ?? 180,
      tilt: v1.roof_tilt ?? 35,
      shading: 0,
    }],
  });
}

alter table public.offers enable row level security;

-- Planners can only read offers from their tenant
create policy "offers_select_own_tenant"
  on public.offers for select
  using (tenant_id = auth.jwt()->>'tenant_id');

-- Configurator (anon) can only write its own offer id
create policy "offers_insert_own_session"
  on public.offers for insert
  with check (session_id = current_setting('request.session_id', true));

-- The configurator can also read back its own offer id — as long as it
-- knows the session id. This is what makes "share configuration by link" work.
create policy "offers_select_own_session"
  on public.offers for select
  using (session_id = current_setting('request.session_id', true));

export class EconomicsUtils {
  static DEFAULT_YEARS_FOR_CALCULATION = 25;
  static ELECTRICITY_PRICE_YEARLY_INCREASE_PERCENTAGE = 0.04;

  static calculate_electricity_price_list(
    starting_price_cent: number,
    yearly_factor = 1 + EconomicsUtils.ELECTRICITY_PRICE_YEARLY_INCREASE_PERCENTAGE,
    max_years = EconomicsUtils.DEFAULT_YEARS_FOR_CALCULATION,
  ): number[] {
    const list = [starting_price_cent];
    for (let y = 1; y < max_years; y++) list.push(list[y - 1] * yearly_factor);
    return list;
  }

  static calculate_payback_period(profit_list: number[], total_cost: number): number {
    let years = 0, cumulative = 0;
    while (total_cost > cumulative && years < profit_list.length) {
      cumulative += profit_list[years++];
    }
    const overshoot = cumulative - total_cost;
    return overshoot > 0 && years > 0 ? years - overshoot / profit_list[years - 1] : years;
  }
}

@page {
  size: A4;
  margin: 1.5cm 2cm;
}
@media print {
  .offer-page { break-after: page; }
  .offer-component { break-inside: avoid; }
  .offer-cover { background: var(--brand-bg) !important;
                 -webkit-print-color-adjust: exact; }
  .no-print { display: none !important; }
}

What three years of operation have shown

Three points that turned out to matter more than we thought at the start.

Master data belongs in the database, editorially editable. Every new module type, every change to the feed-in tariff, every new inverter is a row in the back office — no deploy. Over three years of operation there have been two or three legal changes (VAT on PV systems, raised feed-in tariff) that would otherwise have meant code changes each time.

JSON schema versioning carries further than expected. We’re at schema_version: 5 for the system JSON by now. Each version is migrated cleanly on read, so data looks uniform in the frontend without us having to run a Postgres migration over 50,000 systems. If something really doesn’t fit anymore (very old schemas), a nightly cron can rewrite the column — it hasn’t been needed.

RLS catches every refactor. We’ve done three larger frontend refactors (RxJS subjects → signals; lazy-loaded modules → standalone components; Tailwind v3 → v4). On each one, we accidentally dropped a tenant filter somewhere — and nothing happened, because RLS in the database enforced it again. Exactly the defence-in-depth tenant separation deserves.