When Switzerland opened the door to Lokale Energiegemeinschaften in 2025, most of the conversation was about solar panels and lower bills. Fair enough. But a landing page with a signup form was never going to be the product. Grid operators exchange metering data on fixed schedules, allocation runs on fifteen-minute intervals, invoices carry Swiss QR-bill references, and a wrong VAT line is a customer complaint and an accounting problem.
I co-founded Upgrid as CTO in January 2025. The job wasn’t “build an app.” It was to build the billing, allocation, and operator workflows that make community energy legally and financially real, and to ship fast enough to matter while Swiss reform was still fresh. Real money on real invoices, at the same correctness bar I learned at N26.
Swiss energy law recognises three community models, and the platform supports all of them without pretending they are the same workflow with different labels. A ZEV (Zusammenschluss zum Eigenverbrauch) is a self-consumption association behind a shared grid connection. A vZEV is its virtual form, where members are not physically behind the same connection. A LEG (Lokale Energiegemeinschaft) is the local energy community model that the 2025 reform opened up. Each carries its own metering, allocation, and billing rules.
Who the platform serves
Every product decision at Upgrid starts with who you’re optimizing for, and on the supply side we serve three operator models that want opposite things from the same codebase.
Consumers want zero friction: find a community, understand the savings, sign a contract, done. They will not read a manual about Swiss grid topology. Full operator accounts are the other extreme. Grid operators and energy retailers run communities end to end, from community formation and meter wiring through allocation review, invoice generation, Bexio sync, and exception handling. They live in the product daily.
Between those sit two lighter models. Co-brand operators, mostly municipalities and solar installers, bring members but don’t run billing themselves, so Upgrid operates the communities on their behalf behind branded join flows and contract-intent triage. Affiliates refer consumers and earn a cut, with no operator console and no community management, just tracked signups and attribution.
As CTO I own the architecture, but I also act as PM and marketing when the bottleneck is clarity rather than code. Savings calculators, LEG explainer content, signup funnel instrumentation, and operator onboarding UX all land on the same roadmap as Postgres migrations.
The architecture bet: monorepo at small-team scale
At N26 I spent years inside a ~200-service estate. The most valuable work I did there was often consolidation, pulling scattered fraud rules into one stateful stream because distribution was causing latency rather than defending against it.
Upgrid is the opposite call. We’re a small team shipping a regulated, money-handling platform. Seven apps and ~70 workspace packages with shared types, one Postgres schema, and one CI pipeline beats microservice coordination when real coupling is high and team size is low. At N26, service boundaries matched org boundaries and there were enough teams to justify the integration tax. Here there aren’t. Shared types remove a whole class of contract bugs, one Postgres database with row-level security handles multi-tenancy, and CI ratchets let architecture improve weekly instead of through big-bang migrations. The coupling in this domain is real. Pretending otherwise wouldn’t have made it go away.
Topology should follow team size and the coupling that actually exists. For the full stack tour — apps, metering, allocation, billing, delivery — see Engineering at Upgrid.
The money path
The path from grid data to customer invoice crosses ingestion, allocation, billing, PDF generation, and accounting sync, and every step has a Swiss-specific rule attached. It starts with SDAT, the standardised format Swiss grid operators use to deliver metering data, and ends inside Bexio, the accounting system operators actually close their books in.
A UI typo is embarrassing. A wrong allocation on a large vZEV community is an out-of-memory crash, a support ticket, and a recalculation job. A wrong VAT line on a Swiss QR-bill, the standardised payment slip every Swiss invoice carries, is a dispute with a customer who is also a member of a community you have to keep running. We treat the money path with the paranoia I brought from financial crime prevention: observability on ingestion, idempotent jobs, and tests on the billing engine before we polish marketing pages.
Contract intents versus live contracts is another example. A prospect signing up through a co-brand operator or affiliate link isn’t a billing customer yet. Mixing those lifecycles in one table would have been convenient and wrong, so we separated them early into distinct states and distinct workflows. Retrofitting domain boundaries after invoices exist is expensive.
Applied AI in production
I’ve seen too many “AI-native” pitches that mean “we use Copilot.” Upgrid has three layers, ordered by who benefits.
Layer one is customer-facing. The highest-friction step in consumer onboarding is typing your meter details correctly, so a customer can upload their existing energy bill instead. Extraction runs through the Vercel AI Gateway with structured output and validation before anything reaches the contract intent, and PostHog tracks the whole funnel: upload started, extraction succeeded, fields accepted. Layer two is company-facing: the company brain lets ops self-serve against live data and an indexed schema. Layer three is engineering-facing: the agent harness encodes migration rules, test gates, and a touch-it-migrate-it policy in CI.
All three need guardrails. Only the first two need to work when I’m not in the room.
Beyond the keyboard
None of that matters if nobody signs up. As co-founder I spent serious time on go-to-market: a savings calculator, LEG reform content, SEO guides, co-brand landing pages for municipalities and installers, affiliate attribution, and signup instrumentation built like production software.
Acquisition comes from referral, direct, organic social, paid search, and organic search. There was no single growth hack. Co-brand pages for municipalities and installers, affiliate links, and Upgrid-owned SEO content all feed the same join flow. That flow is instrumented properly: join_community.* events track steps, field errors, abandonments, and CTA clicks rather than pageviews. Contract intents arrive from web signups, operator-assisted onboarding, and partner channels, and a community gets assigned by auto-selection or operator triage before the intent becomes a live contract.
Those three numbers are the ones worth quoting, because they reflect actual product scale. PostHog is how we iterate on the join flow week to week, but the event taxonomy evolved over time. Point-in-time funnel exports from early instrumentation undercount submissions that came through operator onboarding, co-brand partners, and channels we hadn’t wired yet.
If I were starting again I would put observability and infrastructure-as-code on ingestion from day one, because SDAT is the root of the money path and the monitors should have shipped with the first ingestion job rather than after the first silent failure. I would version the grid data contracts like a schema registry, since metering formats and allocation inputs change and you want to fail loudly on drift. I would ship operator UX before consumer polish, because operators live in the product and a beautiful landing page doesn’t help when community formation and billing exceptions are painful. And I would run more experiments wherever regulation allows, instead of debating join flows in meetings.
Local energy is a systems, regulation, and go-to-market problem. The teams that win will be the ones who treat billing correctness and signup instrumentation with the same seriousness fintech treats fraud.
Questions
What is a ZEV, vZEV, or LEG in Swiss energy law?
They are the three community models Upgrid supports. A ZEV (Zusammenschluss zum Eigenverbrauch) is a self-consumption association behind a shared grid connection. A vZEV is the virtual variant, where members are not physically behind the same connection. A LEG (Lokale Energiegemeinschaft) is the local energy community model Swiss reform opened in 2025. Each has different metering, allocation, and billing rules.
Should a small team use a monorepo or microservices?
Let team size and real coupling decide. Upgrid runs seven apps and ~70 workspace packages with shared types, one Postgres schema with row-level security for multi-tenancy, and a single CI pipeline, because coupling in a regulated billing domain is genuinely high and the team is small. N26’s ~200-service estate made sense for the opposite reason: enough teams that service boundaries matched org boundaries.
What does it take to bill a Swiss energy community?
Five steps. SDAT metering data is ingested from the grid operator, consumption is allocated across members on fifteen-minute intervals, the billing engine prices it, a Swiss QR-bill PDF is generated, and the result syncs to Bexio for accounting. A wrong VAT line on the QR-bill is both a customer dispute and an accounting problem, so the billing engine gets tests before the marketing pages get polish.
How large is Upgrid?
2,000+ community members, 250+ communities, and 150+ municipalities on upgrid.ch.