Energy Software Development: How We Built a Swiss Electricity Tariff Platform in 1 Month
About the Client
Strompreise Schweiz publishes Swiss electricity tariffs in a form both people and machines can use. Anyone building an energy product runs into the same problem: a household's electricity price is not one number. In Switzerland, more than 600 distribution system operators each set their own tariffs, and a single bill combines an energy price, grid usage charges, metering fees, and municipal and cantonal levies, often with separate high and low tariff periods. The public reference, ElCom's portal, reports averages for standard consumption profiles. That works for a news headline, but not for a household comparing offers or a heat pump deciding when to run. The founder brought us in to build a platform that stores every component of every tariff, explains it to consumers, and serves it to devices through an API.
Launch Results
600+
Swiss energy providers in the platform's DSO registry
Daily
optional automated re-validation of supplier tariff data
1 month
from kickoff to working MVP
How we handled the hard parts
A data model for real tariffs
Each tariff is stored as separate components (energy, grid usage, metering, DSO fees, regional levies, feed-in tariff), each with its own unit: per kWh, per month, per kW of peak power, or per kVarh of reactive energy. Time-of-use rules cover high and low tariff windows by day and hour, and dynamic tariffs carry a link to their live pricing feed.
New suppliers without code changes
A utility points the platform at a public JSON file that follows the VSE OpenAPI 3.0.3 tariff schema. The file is validated on import and, with auto-refresh on, fetched and re-validated every day. Adding a supplier means adding a data source. The core application stays untouched.
One tariff, two audiences
Consumers see a price breakdown by component and quarter, with the renewable share and VAT rate listed. Smart energy controllers get the same tariff as structured JSON from a versioned REST API with filtering, sorting, and pagination.
Four languages from day one
Swiss consumers expect German, French, or Italian, and many API users work in English. The platform ships in all four, across the public tariff pages, the API documentation, and the logged-in dashboard.
How the project ran
- Discovery - We mapped how Swiss tariffs are actually built, from high/low tariff windows to power pricing per kW, and how the VSE, the Swiss Federal Office of Energy, and ElCom publish tariff data. Those formats set the shape of the data model.
- Design - We designed two views of every tariff: an itemized breakdown a consumer can read, and a schema a device can parse. Utilities got their own onboarding path, which starts by selecting their DSO from the official Swiss registry.
- Development - We built the platform on Next.js and Node.js with Supabase (PostgreSQL), with a versioned REST API, per-organization API keys, and request logs that show volume, error rate, and response times.
- Launch and beyond - The MVP shipped in a month. Since then we have added subscription billing, team roles and invitations, multi-factor sign-in, and an admin panel that syncs the DSO registry from strom.ch.
Technology we chose for this project
Frontend
- React
- Next.js
- Tailwind CSS
- Vercel
- Figma
Backend
- Node.js
- Supabase
- PostgreSQL
- Resend
What We Built
Strompreise Schweiz has three parts that share one tariff database.
For consumers, there's a tariff browser in four languages. Each tariff opens to an itemized breakdown of energy, grid usage, metering, DSO fees, and regional levies, each with its unit, plus validity dates, voltage level, customer type, and the renewable share from the Swiss electricity label. Prices are shown net of VAT with the rate listed, so two tariffs compare on equal terms.
For utilities, there's a self-serve portal. A DSO picks itself from the official Swiss registry, imports its tariffs from a VSE-schema JSON file, and composes them into the products customers browse. Validation errors are flagged before anything is published.
For developers and device makers, there's a REST API with key-based authentication, filters by provider, tariff type, and date, and consistent JSON error codes. Each organization manages its own keys and can see its own request logs.
Building an Energy or Utility Comparison Product?
We've modelled real electricity tariffs, onboarded supplier data through a standard schema, and turned it into pricing people can read. If you're building an energy, utility, or fintech-style comparison product, we can scope it with you and deliver it against fixed milestones.
Result & Impact
Swiss tariff data now has a public home where the components stay separate. A consumer can see why two suppliers differ, whether that's grid charges, a higher base fee, or the energy price itself. A charging station or heat pump controller can read high and low tariff windows directly instead of working from an average.
For utilities, publishing a tariff is now a data task. Once a file follows the VSE schema, the platform checks it every day and flags problems, so supplier coverage can grow without a developer in the loop for each new one.
The same problems show up in any market with regulated, multi-part electricity prices: modelling tariffs accurately, getting supplier data into one schema, and explaining a bill to someone who only wants to know whether they're overpaying. That's the part of this project we'd reuse first.
“MTechZilla increased our development velocity and cut backlog resolution time by over 30%, with deliverables consistently completed on time. The commitment of their developers has been outstanding — it truly felt like they were part of our own team, backed by strong technical know-how.”
Philipp Bruhin
Founder, Strompreise Schweiz
Feedback from the founder on our long-standing partnership and technical expertise.
Frequently Asked Questions
What makes Strompreise Schweiz different from ElCom's tariff portal?
ElCom publishes average prices for standard consumption profiles. Strompreise Schweiz stores each tariff's individual components (energy, grid usage, metering, and levies), including high and low tariff windows and power pricing. That detail is what a consumer needs to compare offers fairly and what a smart device needs to decide when to draw power.
How do energy suppliers add their tariffs?
A utility selects its DSO from the official Swiss registry, then adds a public URL to a tariff file in the VSE OpenAPI 3.0.3 format. The platform validates the file immediately and can re-fetch and re-check it daily. Valid components are then composed into tariff products that appear in the public browser and the API.
How do smart devices use the tariff API?
Devices and energy management systems call a versioned REST API with an API key. They can filter tariffs by provider, type, and validity date and receive structured JSON with each price component, its unit, and its time-of-use rules. Dynamic tariffs include a link to the supplier's live pricing feed.
Can a tariff platform like this be adapted to another energy market?
The parts that change between markets are the tariff schema, the regulator's data sources, the taxes and levies, and the languages. The component-based data model was built to handle that kind of variation. For a new market, we would start by mapping its tariff structure and supplier data formats before writing any code.
How long does energy software development like this take?
The Strompreise Schweiz MVP took one month with a team of six. Timelines for comparable products depend mostly on how many supplier integrations are needed and how consistent the suppliers' data is. We usually fix scope and milestones in a discovery phase before committing to a delivery plan.