Machs Dir Selbst Solar

Three apps, one data layer — embedded in a learning platform

The platform consists of three Angular 21 apps, each serving a clearly bounded user group and sharing substantial domain logic. They are the tooling layer inside a larger content platform — DIY customers typically consume the learning content first (component basics, sizing rules, regulatory framework, step-by-step self-install videos) before they even start modelling their system in the Builder. That shifts the customer expectation: people who land here don’t want to be advised, they want tools.

Builder — the customer-facing inquiry app. The customer enters an address, models their roof segments in a maps editor (polygon-drawing over satellite imagery), defines module areas, and roughly picks what to inquire about. Out comes a rough price range and a bill of materials and tools for a DIY approach. Anyone who’s already learned from the videos and guides what an MC4 connector is and how a string layout works gets through on their own. Solario gets an internally consistent, realistic inquiry; the customer gets an honest expectation.

Configurator — the detailed offer app, which the customer enters once Solario has worked on the inquiry. The finished offer lives here: concrete module series, concrete inverter, optional components with surcharge, detailed economic statistics. The customer can swap materials (premium vs base module), sees the impact on price, yield and payback instantly, and can accept the offer directly — no appointment, no phone call.

Planner — the internal tool, built around automation. From a Builder inquiry, the Planner drafts an offer, fills in missing technical details from master data (which wiring fits, which inverter matches which string layout, which subsidies apply regionally), and the planner only checks and ships it. A single planner can handle the volume that would tie up several consultants in the classic sales line. Master-data editing (manufacturers, modules, inverters, electrical firms, subsidies, price assumptions) happens here too.

All three share libs/economics (cashflow, annuity, price escalation, payback) and libs/utils. nx affected builds and tests only what a change actually touches — across four targets per app, it’s the difference between a pleasant CI and an unusable one.

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

  static calculate_payback_period(profit_list_euro: number[], total_cost_euro: number): number {
    let years = 0;
    let cumulative = 0;
    while (total_cost_euro > cumulative && years < profit_list_euro.length) {
      cumulative += profit_list_euro[years];
      years += 1;
    }
    const remaining = cumulative - total_cost_euro;
    if (remaining > 0 && years > 0) {
      return years - (remaining / profit_list_euro[years - 1]);
    }
    return years;
  }
}

What the preview infrastructure actually does

The standout piece of infrastructure here isn’t a single app, it’s preview.yml. It turns every PR into a complete, isolated test environment: its own Postgres DB, its own three containers, its own three URLs.

For every PR the workflow runs through these steps:

1. Ensure a Supabase branch. Look up the preview branch matching the PR’s git branch via the Management API, or create one. Poll up to 15 minutes for ACTIVE_HEALTHY, then read branch-specific credentials (DB password, anon key, JWT secret).
2. Sync edge function secrets. Preview branches inherit functions from the parent project but not their secrets — without this step, every Deno.env.get(...) returns undefined on previews.
3. Bootstrap dashboard-only schemas. The supabase_functions schema and http_request trigger exist in production because they were created via a dashboard click. They don’t exist on a branch — the workflow installs a no-op stub with the same signature so migration triggers don’t fail.
4. Set the vault JWT secret. Custom JWT-signing functions read app.jwt_secret from the Postgres vault. A fresh branch lacks that row — the workflow inserts it with the branch’s own JWT secret so PostgREST/GoTrue can verify the self-issued tokens.
5. Push migrations and edge functions. supabase db push --include-all and supabase functions deploy sync the branch with the PR HEAD. On opened/reopened, seed.sql runs too; on synchronize it doesn’t (the seed isn’t idempotent).
6. Build and deploy affected apps. nx show projects --affected --type=app produces the list. For each, build a Docker image with PR-specific build args, push to GHCR, trigger Coolify’s /api/v1/deploy with the new tag.
7. Update the PR comment. A sticky comment lists the three preview URLs; on opened, a Nextcloud Talk message also goes out so the team knows the preview is live.
8. Teardown on closed. Delete the Supabase branch and tear down three Coolify previews via DELETE /api/v1/applications/<uuid>/previews/<pr>.

Highlights

- name: Build, push to GHCR, trigger Coolify deploy
  env:
    SUPABASE_URL: ${{ steps.supabase.outputs.url }}
    SUPABASE_ANON_KEY: ${{ steps.supabase.outputs.anon }}
    PLANNER_URL: ${{ steps.urls.outputs.planner }}
  run: |
    image="ghcr.io/$repo/${name}:pr-${PR_NUMBER}"
    docker buildx build \
      --build-arg "SUPABASE_URL=${SUPABASE_URL}" \
      --build-arg "SUPABASE_ANON_KEY=${SUPABASE_ANON_KEY}" \
      --build-arg "PLANNER_URL=${PLANNER_URL}" \
      --tag "$image" --push .

    curl -sS -X POST -H "Authorization: Bearer $COOLIFY_TOKEN" \
      "$COOLIFY_URL/api/v1/deploy?uuid=$uuid&pr=$PR_NUMBER&docker_tag=pr-${PR_NUMBER}"

deadline=$(( $(date +%s) + 900 ))  # 15m
while : ; do
  branch=$(curl -sS -H "Authorization: Bearer $TOKEN" \
            "https://api.supabase.com/v1/branches/$branch_id")
  status=$(echo "$branch" | jq -r '.status // empty')
  case "$status" in
    ACTIVE_HEALTHY|FUNCTIONS_DEPLOYED|MIGRATIONS_PASSED)
      break ;;
    MIGRATIONS_FAILED|FUNCTIONS_FAILED)
      echo "::error::Preview branch failure: $status"
      exit 1 ;;
  esac
  [[ $(date +%s) -ge $deadline ]] && { echo "::error::timeout"; exit 1; }
  sleep 10
done

CREATE SCHEMA IF NOT EXISTS supabase_functions;
DO $bootstrap$
BEGIN
  IF NOT EXISTS (
    SELECT 1 FROM pg_proc p
      JOIN pg_namespace n ON p.pronamespace = n.oid
    WHERE n.nspname = 'supabase_functions' AND p.proname = 'http_request'
  ) THEN
    EXECUTE $body$
      CREATE FUNCTION supabase_functions.http_request() RETURNS trigger
      LANGUAGE plpgsql AS $fn$ BEGIN RETURN NEW; END $fn$
    $body$;
  END IF;
END $bootstrap$;

- name: Compute affected apps
  id: affected
  run: |
    if [[ "${{ github.event.action }}" != "synchronize" ]]; then
      # opened/reopened: build all three apps
      { echo "builder=true"; echo "planner=true"; echo "configurator=true"; } \
        >> "$GITHUB_OUTPUT"
      exit 0
    fi
    affected=$(pnpm exec nx show projects --affected --type=app)
    for app in builder planner configurator; do
      if echo "$affected" | grep -qx "$app"; then
        echo "${app}=true" >> "$GITHUB_OUTPUT"
      else
        echo "${app}=false" >> "$GITHUB_OUTPUT"
      fi
    done

# Suspenders: is_default != true guarantees we can never select the prod branch.
branch=$(echo "$branches" | jq -c \
           --arg g "$PR_BRANCH" \
           '[.[] | select(.git_branch == $g and .is_default != true)] | .[0] // empty')
if [[ -z "$branch" ]]; then
  echo "No Supabase preview branch for $PR_BRANCH — nothing to delete"
  exit 0
fi
branch_id=$(echo "$branch" | jq -r '.id')
curl -sS --fail -X DELETE \
  -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
  "https://api.supabase.com/v1/branches/$branch_id" > /dev/null

What a year of operation has shown

Three observations we wouldn’t have seen as clearly on day one.

The preview pipeline is an onboarding tool. Onboarding new developers takes basically zero minutes — they open a PR, get three URLs, click in. The real strength isn’t code review, it’s letting external stakeholders (Solario sales, designers) work on a real version without a local setup.

Edge function secrets are the quiet stumbling point. About half the preview problems we’ve seen had the same trigger: a new secret in apps/supabase/functions/.env that didn’t get added to the sync list. We enforce it via CODEOWNERS now.

Build args eliminate a class of “works locally, not in preview” bugs. The first version used build-time substitution from env vars into environment.preview.ts (a sed-based script). It works but is fragile — every new env has to stay in sync across two lists. Build args put it all in one place.