Danish Electricity Price
Comparison Drupal

Electricity prices in Denmark are genuinely hard to compare. Providers mix fixed, variable, and combined rates, charge different fees depending on how you pay, bind you for different lengths of time, and quote different prices for West and East Denmark. Faced with all of that, most people cannot tell which deal is actually cheapest for their own home. A Danish comparison site wanted to answer that question in seconds, but it had no engine to do it.

Electricity Price Comparison is that engine. It is a custom Drupal build for a Danish electricity comparison site: an Electricity Offer content type for structured offer data, live multi-select filters, and a monthly price calculated from each visitor’s own usage. Visitors set their expected yearly consumption and their region, tick the filters they care about, and see every offer re-priced and re-sorted for their situation, cheapest first.

Put simply, the price a visitor sees is theirs, not a generic headline number. Move the usage slider or change a filter and every offer’s monthly cost recalculates and the list re-sorts, instantly, without a page reload. The site owner adds and edits offers from the Drupal admin, and the custom code stays small so the whole thing is cheap to maintain.

The Starting Point: A Real Comparison Tool, Not a Static List

The client wanted something that worked like the leading Danish comparison sites, where the number on screen reflects your household and the filters feel alive. A static table of prices could never do that. The requirements set the bar.

• Structured offer data. There was no place in the CMS to enter an offer with its logo, kWh price, price type, binding period, fees, and provider link, so filtering and calculation were impossible.
• Prices that depend on the visitor. A monthly price only means something when it is based on the visitor’s own yearly usage, and it has to change as that usage changes.
• Honest handling of hidden fees. Providers charge different fees for BetalingsService, MobilePay, debit cards, and payment slips, which changes the real monthly cost.
• Filters that feel instant. Visitors expect to tick several options at once and see results update immediately, with a reset button to clear them.
• Easy for the owner to maintain. The owner wanted to add and edit offers himself, using core and well-supported contributed modules where possible so custom code stays small.

The Build: Set Your Usage, See the Cheapest Deal First

The page puts the filters on the left and the offers on the right. Visitors choose West or East Denmark, move a slider for their expected yearly consumption, and tick filters for price type, binding period, monthly payment, and provider. Mirroring a complex comparison interface this closely, inside the client’s existing site, is where the Drupal development services behind the project earned their keep. A visit flows like this:

1. The visitor opens the electricity price page and chooses West or East Denmark.
2. They set their expected yearly usage on the slider.
3. They tick the filters they care about, combining several at once, with a reset button to clear them.
4. Every offer’s monthly price recalculates from their usage and the list re-sorts, cheapest first.
5. Each offer shows the provider logo, selling-point banners, the monthly price on the first line, and the cost per kWh on the second.
6. A button takes the visitor straight to the provider’s site to sign up.

The monthly price is worked out live as yearly usage divided by twelve, multiplied by the cost per kWh, plus the cheapest monthly payment fee that provider offers; fees a provider does not offer are simply hidden. In the admin, the owner creates each offer as a content item and fills in its fields, and it appears in the list automatically.

Technical Architecture

The comparison runs on Drupal 10, with a dedicated content type for structured offer data, Views for the list and filters, and Twig templates for the layout. The challenge was never creating a content type. It was mirroring a live, multi-select comparison interface with a slider that recalculates every price, correct sorting, and fees that appear only when they apply, all inside the client’s existing site.

• Electricity Offer content type. One node per provider offer, with all eleven required fields, including a Paragraphs fee group for BetalingsService, MobilePay, debit card, and payment slips.
• Views and Better Exposed Filters. The list and its AJAX filters are built on Views with Better Exposed Filters, so multiple selections update the results instantly and a reset clears them.
• Custom price module. The one piece Views cannot do alone, the live monthly-price formula, lives in a small custom module using PHP and Drupal behaviours in JavaScript. Keeping bespoke logic to a single module like this is the sort of focused web application development that stays maintainable for years.
• Data-driven filters. Filter options are read from the field’s allowed values and taxonomy terms, so they always match what the owner enters in the admin.
• Deployment. Git, Composer, and Drush config export make releases repeatable and safe, which also made room for the client’s planned theme redesign.

The part worth engineering carefully was the calculation itself. Every offer had to recalculate on each slider move, the list re-sort, and the monthly price and per-kWh cost land on the correct lines, matching the reference site exactly. Because the price logic and filters live in a custom module and Views configuration rather than the theme, a future theme only needs its own Twig templates.

Challenges Solved

In an early version the monthly prices did not change as the usage slider moved, so the calculation was rewired to recalculate every offer on each slider move using the agreed formula, then re-sort the list and place the figures on the correct lines. The first filter build used fixed option lists; after client feedback the filter options were connected to the field values and terms, so the filters always reflect the data the owner enters. Development had also accumulated extra modules, test content, and debug logging, so at the client’s request the unused modules were uninstalled, test data cleaned up, and browser logging removed, leaving only what the feature needs. Finally, the client planned a theme redesign after launch, which is exactly why the price logic sits in a custom module and the config was exported and documented on video for the handover.

A comparison that genuinely prices for each household is what makes energy and utility comparison businesses worth trusting, because the more accurate the number, the more visitors act on it.

The Result

The electricity comparison went live in September 2024, was refined through two rounds of feedback, and was approved in October 2024 with a strong review. The offers carry full parity with the reference site, eleven fields including the five-fee group; the filters are multi-select, instant, and resettable; the default sort puts the cheapest deal at the top; and the site owner can add a new offer as a single content item. The site answers the question people actually have: which deal is cheapest for me.

The build holds up because the comparison logic is structured, data-driven, and kept out of the theme, so it survives a redesign. If you are building a comparison or marketplace engine, you can hire full-stack developers who have built this kind of live-pricing Drupal tool, or tell us how your offers are priced and we will turn the rules into a calculator your visitors can trust.

Frequently Asked Questions

What does the electricity comparison engine do?

It lets visitors to a Danish comparison site find the cheapest electricity deal for their own home. They set their yearly usage and region, apply filters, and see every provider’s offer priced for their usage and sorted cheapest first, with a button through to each provider.

How is each monthly price calculated?

The price is worked out live as yearly usage divided by twelve, multiplied by the cost per kWh, plus the cheapest monthly payment fee that provider offers. Fees a provider does not offer are hidden, and every price recalculates whenever the usage slider moves.

Why build it on Drupal 10?

Drupal 10 gives structured content and a clear admin, which the comparison depends on. Each offer is a dedicated content type with defined fields, and that structure is what makes accurate filtering, sorting, and calculation possible without resorting to free text.

How do the filters update so quickly?

The filters are built on Views with Better Exposed Filters using AJAX, so results update without reloading the page. Visitors can combine several selections at once, reset them with one button, and the options are read from the real field values so they always match the data.

Can the site survive a future theme redesign?

Yes. The price logic and filters live in a custom module and Views configuration rather than in the theme, so a new theme only needs its own Twig templates. The module, formula, and config export were documented on video at handover for exactly that reason.