Forem: Joshua

I Built a WordPress Plugin That Calculates Snow Loads Per DIN EN 1991-1-3 – Using OpenRouteService for Elevation Data

Joshua — Tue, 10 Mar 2026 14:00:00 +0000

A WordPress plugin that calculates the structural snow load for any address in Germany – using geocoding, elevation data, and the actual DIN EN 1991-1-3 formulas – and then shows how many days per year a terrace canopy would extend outdoor living. Two tools in one plugin, one address input, two parallel AJAX calls.

I built this for a company that sells terrace canopies, conservatories, and carports. Their sales team needed two things for every customer consultation: what's the snow load at this location (for structural calculations), and how many extra days of terrace use does a canopy provide (for the sales pitch). Before, they used a buggy Excel spreadsheet for the snow load and guessed the terrace days.

How the Snow Load Calculation Works

Germany is divided into five snow load zones (1, 1a, 2, 2a, 3). Each zone has its own formula from DIN EN 1991-1-3:

Zone 1:  sk = 0.19 + 0.91 × ((A + 140) / 760)²
Zone 1a: sk = 1.25 × (0.19 + 0.91 × ((A + 140) / 760)²)
Zone 2:  sk = 0.25 + 1.91 × ((A + 140) / 760)²
Zone 2a: sk = 1.25 × (0.25 + 1.91 × ((A + 140) / 760)²)
Zone 3:  sk = 0.31 + 2.91 × ((A + 140) / 760)²

Where A = elevation above sea level in meters and sk = snow load in kN/m².

The plugin needs two inputs: the snow load zone and the elevation. Getting both from just an address requires three steps.

Step 1: Postal Code → Snow Load Zone

A 1.3 MB JSON file maps every German postal code to its snow load zone. This runs as a local lookup – no API call needed.

$zones = json_decode(file_get_contents('snowloadzones.json'), true);
$zone = $zones[$plz]; // e.g. "2"

This is the most reliable part. The postal code mapping is static data from the DIN standard. No external dependency, no rate limits, instant.

Step 2: Address → Coordinates → Elevation

This is where OpenRouteService comes in. Two API calls, running server-side via PHP:

Geocoding: The structured address (street, number, postal code, city) is sent to /geocode/search/structured. Returns latitude and longitude.

Elevation: The coordinates are sent to /elevation/point. Returns the height above sea level in meters.

// Simplified flow
$coords = openroute_geocode($street, $nr, $plz, $city);
// → ['lat' => 53.5511, 'lng' => 9.9937]

$elevation = openroute_elevation($coords['lat'], $coords['lng']);
// → 18 (meters above sea level)

I chose OpenRouteService over Google Maps because it's free for moderate query volumes and doesn't require a credit card. The elevation data comes from SRTM (Shuttle Radar Topography Mission) – accurate enough for snow load calculations where a few meters don't change the result significantly.

Step 3: Apply the Formula

Zone + elevation → formula → result.

For an address in Hamburg (zone 2, 18m elevation):

sk = 0.25 + 1.91 × ((18 + 140) / 760)²
sk = 0.25 + 1.91 × (158 / 760)²
sk = 0.25 + 1.91 × 0.0432
sk = 0.33 kN/m²

That's 34 kg per square meter. The plugin displays both kN/m² and kg/m², plus the full formula so the user can verify the calculation.

The Terrace Time Calculator

Same address input, completely different calculation. While the snow load AJAX call runs, a parallel request goes to a weather data API that returns historical temperature statistics for the location.

The plugin sorts all 365 days into five categories:

Category	Temperature	Meaning
Ice days	below 0°C	Not usable
Cold days	0–10°C	Usable with conservatory
Potential days	10–25°C	Usable with terrace canopy
Summer days	25–30°C	Pleasant without any cover
Hot days	above 30°C	Too hot – canopy shade helps

Without a canopy, only summer days count as real terrace days. For Hamburg, that's about 29 days per year (8%).

The magic happens with two interactive checkboxes: "Terrace canopy" and "Conservatory". When the user checks "Terrace canopy", the potential days are added – the pie chart animates from gray to green, and the number jumps from 29 to around 229 days. Check both, and you're at 344 days (94%).

The pie chart is rendered with Chart.js. The animation on checkbox click is the key UX moment – watching the chart turn green while the number climbs from 29 to 344 is more persuasive than any brochure.

Why Two Tools in One Plugin?

Because they belong together in practice. Every customer consultation needs both: the snow load for structural engineering and the terrace time visualization for the purchase decision.

The sales rep enters the customer's address once. Both AJAX requests fire in parallel. Seconds later, both results are on screen:

Left side: Snow load, structural calculations, rafter sizing for different profiles
Right side: Pie chart showing terrace potential, animated checkboxes for products

The snow load determines the technical requirements: which rafter profile, what glass thickness, how much reinforcement. The terrace time calculator delivers the sales argument: "At your location, a terrace canopy gives you 200 extra days of outdoor living per year."

// Both requests fire in parallel
$.when(
  $.ajax({ url: ajaxurl, data: { action: 'calc_snowload', ... } }),
  $.ajax({ url: ajaxurl, data: { action: 'calculate_regentage', ... } })
).then(function(snowResult, weatherResult) {
  renderSnowLoad(snowResult);
  renderTerraceTime(weatherResult);
});

The Expert Mode

There are actually two modes. The standard mode is public on the company website – anyone can enter an address, get their snow load and terrace potential, and leave their email for the full report. Classic lead magnet.

The expert mode is for the sales team only. It adds input fields for the planned canopy dimensions: width, depth, glass thickness, height offset, rafter profile. The plugin then calculates not just the snow load but the actual load on the planned structure – including snow load with and without wedge factor, total weight in kg, and rafter sizing across all available profiles (S through XL+).

It checks deflection and stress limits for the company's own product lines and shows green checkmarks for profiles that pass. The sales rep can configure the exact canopy in front of the customer and show immediately whether the chosen profile handles the local snow load.

Architecture Overview

Address Input (Street, Nr, Postal Code, City)
              │
      ┌───────┴───────┐
      ▼               ▼
  SNOW LOAD      TERRACE TIME
      │               │
  PLZ → JSON      Weather API
  (Zone 1-3)    (Temperature data)
      │               │
  Geocoding           │
  (→ Coordinates)     │
      │               │
  Elevation           │
  (→ Height ASL)      │
      │               │
  DIN Formula      Sort days
  (Zone + Height)  (5 categories)
      │               │
      ▼               ▼
  0.33 kN/m²     29 → 344 days
  (34 kg/m²)     (+315 with canopy)
      │               │
      └───────┬───────┘
              ▼
      Result Display
  (Snow load + Pie chart)

The plugin is ~12 files total. PHP backend, jQuery frontend, two JSON data files, email and print templates. No build step, no npm, no framework. It's a WordPress plugin – it gets uploaded, activated, and works.

What I'd Do Differently

Caching. Every calculation makes two live API calls to OpenRouteService. For a tool used by a sales team with maybe 20 queries per day, that's fine. But if the public version gets heavy traffic, I'd add transient caching keyed by postal code + street. Most addresses in the same postal code area have nearly identical elevations.

The weather data API is a separate plugin that I didn't build. If I were starting fresh, I'd integrate it into the same plugin and use Open-Meteo's free historical weather API. One less dependency.

TypeScript instead of jQuery. The plugin was built for a specific WordPress setup where jQuery was already loaded. For a new project, I'd use vanilla JS or a small reactive framework for the interactive elements.

I'm Joshua, freelance web developer from Hamburg. I build WordPress plugins, Shopify themes and custom web tools. More case studies on hafenpixel.de.

Building a SaaS Licensing System With WooCommerce – No Custom Tables, No License Keys

Joshua — Tue, 03 Mar 2026 14:00:00 +0000

You can run a SaaS product on WooCommerce. Not a huge one – but for a niche tool with a few hundred users, it works surprisingly well. No custom database tables, no license key management, no Stripe integration. Just WooCommerce Subscriptions, a custom plugin, and WordPress User Meta.

I built this for a client who runs a price calculation tool for hair salons in Germany. The tool helps salon owners calculate their service prices based on employee count, material costs, and time. Over 100 salons pay annual subscriptions to use it. The entire licensing, payment, and access control system runs on WooCommerce.

Here's how it works technically – and why I chose this approach over a traditional SaaS stack.

The Setup

The client had a working tool but needed a way to sell access to it. The requirements:

Annual subscriptions with automatic renewal
6 license tiers based on salon size (0, 2, 5, 10, 15, 30 employees)
Self-service purchase and renewal
The client (non-technical) should be able to manage everything himself

The obvious choice would have been a custom SaaS stack: Stripe Billing for payments, a custom backend for license management, a separate admin panel. That would have cost €15,000–20,000 and taken 8–12 weeks.

Instead, I built it on the existing WordPress installation where the tool already lived.

The Key Insight: User Meta Instead of License Keys

Traditional license systems generate keys, store them in a database, validate them on every request. Keys can leak, need rotation, and require a custom management UI.

I skipped all of that. The license is tied to the WordPress user account. When someone buys a subscription, four values are written to wp_usermeta:

// That's the entire "license"
update_user_meta($user_id, 'sve_license_active', 'yes');
update_user_meta($user_id, 'sve_license_expiry', $expiry_timestamp);
update_user_meta($user_id, 'sve_license_level', $level);
update_user_meta($user_id, 'sve_license_sku', $product_sku);

No custom tables. No license keys. No keys that can leak or be shared. The license is bound to the WordPress account – the user logs in and has access. That's it.

This works because the tool runs as a WordPress plugin on the same installation. It's not an external SaaS that needs API authentication. It's a page on the same site, protected by standard WordPress login.

Access Control

A single function checks access and returns one of three states:

function check_access($user_id) {
    $active = get_user_meta($user_id, 'sve_license_active', true);
    $expiry = get_user_meta($user_id, 'sve_license_expiry', true);

    if ($active !== 'yes') return 'none';
    if ($expiry < time()) return 'readonly';
    return 'full';
}

Three states, not two. This is the part I'm most happy with:

full: Active license – create new calculations, full access
readonly: License expired – can still view all old data, but can't create new calculations
none: No license at all

The readonly state is deliberate. When a subscription expires, the user doesn't lose access to their data. They can still log in, see all their calculations, export their data. They just can't create new ones. That's a much better experience than a hard lockout – and it's a strong incentive to renew, because they see exactly what they're missing.

WooCommerce Does the Hard Part

Payment processing, subscription management, renewal reminders, failed payment handling – WooCommerce Subscriptions handles all of it. I just hook into the lifecycle events:

// Activate on purchase
add_action('woocommerce_order_status_completed', 'activate_license');

// Extend on renewal
add_action('woocommerce_subscription_renewal_payment_complete', 'extend_license');

// Deactivate on cancellation
add_action('woocommerce_order_status_cancelled', 'deactivate_license');
add_action('woocommerce_order_status_refunded', 'deactivate_license');

The activate_license function reads the product SKU to determine the license level, calculates the expiry date, and writes the four User Meta values. That's ~30 lines of PHP for the entire activation logic.

PayPal Commerce Platform handles payments. The activation is gateway-agnostic – it triggers on order_status_completed, regardless of whether the customer paid via PayPal, credit card, or bank transfer.

What the Client Can Manage Himself

This was a hard requirement: the client is not technical. He needed to manage everything through the WordPress backend without calling me. He can:

Create and modify license tiers (just WooCommerce products)
Edit all text content on the tool pages
Configure email intervals and content for expiry reminders
Create coupons and upgrade discounts
View all active licenses (it's just a user list with meta fields)

No custom admin panel needed. The WordPress backend is the admin panel.

The Cost Comparison

	WooCommerce Approach	Traditional SaaS Stack
Development time	~4 weeks part-time	8–12 weeks (estimate)
Development cost	Low four figures	€15,000–20,000 (estimate)
Hosting/month	Standard shared hosting	€50–200/month (cloud)
Payment processing	WooCommerce + PayPal	Stripe Billing integration
Admin interface	WordPress backend	Custom-built
License management	User Meta (4 fields)	Custom database + API

The WooCommerce approach was faster, cheaper, and gave the client full control from day one. The tradeoff: it doesn't scale to thousands of concurrent users. But for a niche B2B tool with 100+ licenses, it doesn't need to.

When This Approach Works – and When It Doesn't

WooCommerce as SaaS backend makes sense when:

Your tool already runs on WordPress (or can run as a plugin)
You have hundreds, not thousands of users
Annual or monthly subscriptions with simple tiers
The operator wants self-service management
Budget is limited and time-to-market matters

Use a proper SaaS stack when:

You need real-time features or websockets
Thousands of concurrent users are expected
You need fine-grained API rate limiting
Multi-tenancy with data isolation is required
The product will eventually need its own mobile app

The key question is: does your use case actually need the complexity of a custom stack? For a niche B2B tool with a few hundred users, the answer is often no. WooCommerce gives you payments, subscriptions, user management, and an admin panel out of the box. Adding license control on top is a few hundred lines of PHP.

Anonymous Analytics Bonus

One unexpected benefit: since all calculations run through the WordPress plugin, I was able to add anonymous aggregated analytics. The client can see average calculation values, pricing patterns, and employee planning trends across all salons – without seeing individual data.

This gives him benchmark data for product improvement and a potential value-add for users: "See how your prices compare to the average salon in your region."

I'm Joshua, freelance web developer from Hamburg. I build WordPress plugins, Shopify themes and custom web tools. More case studies on hafenpixel.de.

I Built 3 Shopify Cart Features Without a Single App – Just Liquid & JS

Joshua — Tue, 24 Feb 2026 14:00:00 +0000

Three Shopify features that usually require three separate apps – a progress bar, an auto-add free gift, and cart recommendations – can be built with custom Liquid and JavaScript in a single solution. No monthly fees, no extra HTTP requests, no performance hit.

I'm a freelance developer from Hamburg, and I recently did exactly this for a Shopify store called Bodenständig. They sell garden supplies for home growers – seeds, fertilizer, edible plants. The store was running Monk for the progress bar and gift logic. The cart recommendations didn't exist before – I built all three features from scratch as a single custom solution, replacing the app in the process. It worked, but it loaded its own script bundle, injected its own CSS, and made extra API calls on every page load. On mobile – where most of their customers shop – it was noticeably slow.

Here's how I replaced it all with code that lives directly in the Dawn theme.

The Problem With Shopify Apps

Every Shopify app loads its own JavaScript, its own CSS, and often makes additional external requests – on every single page view. Three apps for cart features can add hundreds of milliseconds to your page load.

Apps run as an external layer on top of your theme. They have to be generic because they need to work across thousands of different stores. That makes them inherently heavier and less optimized than a custom solution.

And they charge monthly. In this case, about €50/month. That's €600/year. Over three years, €1,800. For code that doesn't belong to the store owner and disappears the moment you unsubscribe.

Feature 1: Progress Bar

The progress bar shows customers in real-time how close they are to two thresholds: free seed packet at €30, free shipping at €60.

The initial state is calculated server-side in Liquid, so the bar renders correctly the instant the cart drawer opens – no flicker, no loading state. JavaScript takes over for subsequent updates.

{% raw %}
{%- assign cart_total_without_gift = 0 -%}
{%- for item in cart.items -%}
  {%- assign is_gift_item = false -%}
  {%- for prop in item.properties -%}
    {%- if prop.first == '_gift' and prop.last == 'true' -%}
      {%- assign is_gift_item = true -%}
    {%- endif -%}
  {%- endfor -%}
  {%- unless is_gift_item -%}
    {%- assign cart_total_without_gift = cart_total_without_gift | plus: item.final_line_price -%}
  {%- endunless -%}
{%- endfor -%}
{%- assign progress_pct = cart_total_without_gift | times: 100 | divided_by: 6000 -%}
{% endraw %}

Important detail: the progress bar calculates the cart value without the gift product. Otherwise, adding the free item would affect the bar – a common bug in app-based solutions.

The text updates dynamically based on the current total:

Under €30: "Noch €X für ein gratis Saatgut-Tütchen" (€X until a free seed packet)
€30–€60: "🎁 Gratis Saatgut gesichert! Noch €X bis gratis Versand" (Free seeds secured! €X until free shipping)
€60+: "✅ Gratis Versand & gratis Saatgut gesichert!" (Free shipping & free seeds secured!)

The bar animates smoothly via a CSS transition on the width property. Two markers at the 30€ and 60€ positions turn green when reached.

Feature 2: Auto-Add/Remove Free Gift

When the cart value hits €30, a free seed packet is automatically added. When it drops below €30, it's automatically removed. The customer doesn't have to do anything.

The gift is a regular Shopify product priced at €0 with status "unlisted" – it doesn't appear in the store but is accessible via its variant ID through the API. When adding it, a hidden property _gift: true is attached. The underscore prefix is key: Shopify hides properties starting with _ from the checkout.

await fetch('/cart/add.js', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    items: [{
      id: GIFT_VARIANT_ID,
      quantity: 1,
      properties: { '_gift': 'true' }
    }]
  })
});

This _gift property identifies the gift item everywhere – when calculating the cart total without the gift, when rendering it differently in the cart (green background, "🎁 Geschenk" badge instead of a price), and when removing it.

The gift item looks different from regular products: green background, no price (shows "Kostenlos" instead), no quantity selector, no remove button – just a 🎁 emoji. The customer immediately sees: this is a gift, it belongs there, they can't modify it.

The hardest part was avoiding race conditions. When a customer rapidly adds or removes products, AJAX calls can overlap. The solution:

An isUpdating flag that blocks concurrent operations
Rate limiting: minimum 3 seconds between gift checks
A debounce timer on cart events (800ms)
A delay after cart operations before checking gift eligibility (1,500ms)

let isUpdating = false;
let lastGiftCheck = 0;

async function checkGiftEligibility() {
  if (isUpdating) return;

  const timeSinceLastCheck = Date.now() - lastGiftCheck;
  if (timeSinceLastCheck < 3000) return;

  lastGiftCheck = Date.now();

  const response = await fetch('/cart.js');
  const cart = await response.json();
  const totalWithoutGift = getCartTotalWithoutGift(cart);
  const hasGift = !!findGiftItem(cart);

  if (totalWithoutGift >= GIFT_THRESHOLD && !hasGift) {
    await addGift();
  } else if (totalWithoutGift < GIFT_THRESHOLD && hasGift) {
    await removeGift(cart);
  }
}

Without these safeguards, rapid clicking could add the gift twice or remove it during a brief intermediate state.

Feature 3: Cart Recommendations

The cart drawer shows product recommendations below the cart items – powered by Shopify's own Product Recommendations API, not an external app.

const url = `/recommendations/products?section_id=cart-recommendations&product_id=${productId}&limit=10&intent=complementary`;
const response = await fetch(url);

The recommendations are rendered as a separate Shopify Section (cart-recommendations). This means they use Shopify's template engine and don't need an external API. No extra JavaScript bundle, no monthly fee, no third-party requests.

The system iterates through all products in the cart and collects recommendations with the complementary intent from Shopify's Search & Discovery algorithm. Products already in the cart are filtered out.

When a customer clicks "hinzufügen" (add), the product is added via AJAX with a hidden property _source: cart_recommendation – this lets the store owner track in their orders which products came from recommendations.

A MutationObserver on the cart items container detects DOM changes by the Dawn theme and triggers a recommendation reload. Parallel requests are prevented with a loading flag that has a safety reset after 10 seconds in case something gets stuck.

How All Three Features Work Together

This is the key advantage over three separate apps: all features share a single JavaScript block and react to the same cart events.

The flow on any cart change:

Customer adds a product or changes quantity
Dawn fires a cart:updated event
A central handler waits 800ms (debounce), then fetches the current cart via /cart.js
Progress bar updates with the new cart value
After another 1,500ms, the gift check runs
Recommendations reload in parallel

The debounce and staggered timeouts matter. If a customer clicks "plus" three times quickly, you don't want three cart fetches, three gift checks, and three recommendation loads. The system waits until the click sequence is done, then does one clean update pass.

let cartChangeTimer = null;

function handleCartChange() {
  if (cartChangeTimer) clearTimeout(cartChangeTimer);
  cartChangeTimer = setTimeout(async () => {
    await updateFromCart();
    setTimeout(() => checkGiftEligibility(), 1500);
  }, 800);
}

document.addEventListener('cart:updated', handleCartChange);
document.addEventListener('cart:change', handleCartChange);

The Numbers

	App Solution	Custom Code
Monthly cost	~€50/month	€0
Performance impact	Extra scripts & requests	Zero (theme-integrated)
Customizability	Limited to app settings	Full control
Code ownership	Rental (gone if you cancel)	Store owner's property
Development time	Instant setup	A few days, one-time
3-year cost	~€1,800	One-time dev cost

When Custom Code Beats Apps

Custom code works when the requirement is well-defined, the feature can be solved with Liquid and JavaScript, and the store is a long-term operation.

Custom code wins when:

The function is clearly scoped (progress bars, gift logic, cart recommendations are perfect candidates)
The app causes performance issues
You need a custom look that app settings can't achieve
Monthly app costs exceed the one-time development cost within 6–12 months

An app wins when:

The feature is complex and needs regular updates (subscription management with dunning, complex bundle pricing)
The store owner wants to change settings frequently without a developer
The app brings A/B testing or analytics that would be expensive to rebuild
The store is brand new and it's unclear which features will stick

The rule of thumb: if an app essentially injects CSS and JavaScript to change a frontend display, it can almost always be built better and cheaper with custom code. If an app brings its own backend with a database and complex business logic, custom code usually doesn't make sense.

I'm Joshua, freelance web developer from Hamburg. I build WordPress plugins, Shopify themes and custom web tools. If you want to see the live implementation, check out Bodenständig's shop. More case studies on hafenpixel.de.