Skip to main content
Talk to an expert
ServiceHyvä support

Hyvä support for live Adobe Commerce and Magento stores.

Live Hyvä stores need the same operational support as any other Adobe Commerce or Magento Open Source build. Incidents, extension compatibility, checkout issues, performance regressions and Magento upgrades are governed under one written runbook. We support both Hyvä storefronts and Hyvä Checkout estates we did not originally build.
600+
Commerce projects
40+
Engineers · on staff
31
Years · systems behind commerce
1995
Founded
Contents · 6 sections
  1. 01What Hyvä support covers
  2. 02Selected case studies.
  3. 03How this platform fits the wider commerce estate.
  4. 04Questions we get asked.
  5. 05Clients we build for.
  6. 06Where this fits in the wider estate.
01 · What Hyvä support covers

What Hyvä support covers

Support for existing Hyvä stores
We support live Hyvä storefronts and Hyvä Checkout estates we did not originally build. Stabilisation comes first; bigger change waits until the picture is honest.
Incident response under a runbook
On-call routing, severity definitions, escalation and post-incident review set out in a written runbook the team can actually act on.
Extension and Magento upgrades
Magento and Hyvä release upgrades planned, tested and rolled out without silently breaking the frontend, checkout or extensions.
Extension compatibility over time
Extension drift watched as new Magento and Hyvä versions land. Compatibility surprises spotted before they hit production.
Small improvements that compound
Continuous small UX, performance and merchandising improvements alongside support, not just incident clearance.
PIM, ERP and integration boundary
Where issues live at the integration boundary, we work with the rest of the estate rather than blame the storefront. ERP and PIM still own commercial and catalogue data.
Takeover of inherited builds
Inherited Hyvä builds audited, documented and stabilised before any larger change. The first month deliberately stays conservative on change.
Tracking, tag and consent maintenance
GTM, analytics, server-side tagging and consent stacks maintained as part of support so reporting does not silently drift.
Backups, environments and release path
Environments, deploy paths and backup strategy reviewed early so support is not run on assumptions.
Honest "do not patch, plan it" calls
Where a problem needs a proper fix rather than a patch, we say so on the record and scope the work; quiet patches that paper over issues are not the deal.
02 · Relevant iWeb work
03 · Platform fit and estate context

How this platform fits the wider commerce estate.

Fit against operational shape
Catalogue depth, trade complexity, branch logic and ERP integration named honestly before the platform decision is fixed, not assumed from a vendor demo.
Integration boundary with ERP
ERP owns commercial data, pricing and stock. The commerce platform reads the boundary through governed APIs; the boundary itself is the most important design decision in the estate.
PIM as the catalogue system of record
Deep catalogue governance lives in PIM (Akeneo, Salsify or similar). The commerce platform reads from PIM rather than re-modelling product data in the storefront.
OMS and fulfilment surface
Order management, partial dispatch, returns and customer-visible order state live in operational systems. The platform reads what operations actually did.
Search and merchandising
Native search plus specialist engines (Algolia, Constructor.io) assessed against the actual query mix, not a vendor benchmark. Relevance is a continuous activity.
B2B and trade behaviour
Account-only catalogues, customer-specific pricing, depot stock, quote-to-cart and partial dispatch modelled inside the platform rather than patched at the storefront.
Multi-store and multi-territory
Brand, market and territory storefronts modelled with shared catalogue, pricing and operations rather than parallel sites that drift apart.
Total cost over five years
Licence, hosting, engineering and support modelled honestly across the lifecycle, not just year one. The cheap year-one platform is often the expensive five-year one.
Headless and composable trade-offs
Headless or composable storefronts where they earn their place, not as a default. The trade-off between optionality and integration surface is named upfront.
Operational ownership and runbook
Long-term support, releases and integration ownership inside a UK agency that runs platforms day to day, with a written runbook the on-call team can act on.
Replatform sequencing
Where a platform move is on the table, sequencing by domain, traffic share or territory keeps trading live throughout. Big-bang relaunches are rarely the right shape.
Honest "do not move" advice
Where the existing platform is the right answer, iWeb says so on the record. A senior, written read on the brief is the deliverable, not a sales pitch.
04 · Questions we get asked

Questions we get asked.

Do you support Hyvä builds you did not build?

Yes. Inherited builds are audited, documented and stabilised first. The first month stays conservative on change while the picture gets honest.

What hours does Hyvä support cover?

Cover is agreed per merchant against trading hours, peak periods and risk appetite. The runbook sets out on-call routing and escalation explicitly.

Do you support Hyvä Checkout under the same agreement?

Yes. Storefront and checkout incidents share the same runbook, with conversion impact treated as a first-class severity input.

How do Magento upgrades work under Hyvä support?

Upgrades planned, tested in non-production, scheduled around trading windows and rolled out with extension-compatibility checks and rollback paths.

Will support include small improvements as well as fixes?

Yes. Small UX, performance and merchandising improvements run alongside incident work so the store keeps moving forward, not just staying alive.

How does iWeb choose between platforms?

Against operational shape: catalogue depth, trade complexity, ERP integration, multi-territory rules and five-year cost. The decision is written down with trade-offs, not assumed from a vendor demo.

Where does ERP integration sit in the platform decision?

It is a primary input. Some platforms make ERP integration straightforward, some make it expensive. iWeb names the trade-off rather than hiding it.

Does iWeb deliver headless or composable storefronts?

Where they earn their place. The trade-off between optionality and integration surface is named upfront; composable is not a default.

How is search handled on this platform?

Native search where the query mix supports it; specialist engines (Algolia, Constructor.io) where the catalogue, volume or merchandising appetite justify them. Relevance is a continuous activity.

Where does PIM sit relative to the commerce platform?

PIM owns catalogue truth (attributes, variants, assets, channel readiness). The commerce platform reads from PIM rather than re-modelling deep product data in the storefront.

Can iWeb take over an existing build on this platform?

Yes, where the brief fits. iWeb will give a senior, written read on what is working, what needs remediation and what is honestly fixable, and the first month on support stays deliberately conservative on change.

How does iWeb size a five-year total cost picture?

Licence, hosting, engineering and support across the lifecycle, including the integration surface and operational ownership. The headline year-one number is rarely the honest comparison.

Accreditations & assurance
Gold Commerce Partner
Specialised in Commerce & AI
ISO certified
27001 · 9001 · 42001
Cyber Essentials Plus
Independently verified security
WCAG 2.2 AA
Accessibility embedded by design
Employee-owned
The same team, long term
Next step

Talk to a Hyvä developer

Send the brief. You'll get a written response from a senior expert on the platform, ERP and operational realities we'd look at first, not a pitch deck.
Talk to an expertor see hyvä development →