Hyvä for Magento

The problem is not always “our PageSpeed score is poor”.

More importantly, over time the frontend has become a barrier to the store’s continued development. Each new change is harder, the code is increasingly complex, performance is poor, and a planned redesign would mean adding more layers to a solution that already needs modernisation.

For new Magento implementations, we recommend Hyvä by default. We also rebuild existing storefronts with Hyvä when their legacy frontend layer has begun to limit further development.

We can handle the entire process: from analysis and UX/UI through development, checkout, testing and launch.

A free 30–60 minute call. We will discuss your current frontend, performance results and implementation constraints. We will provide an initial assessment of whether Hyvä is the right direction and what analysis is needed.

Signals

When the frontend starts becoming a limitation

Problems usually emerge gradually.

  • The store is slow despite a healthy backend response time.
  • A seemingly small change requires work across several layers of code.
  • Further customisations increase maintenance costs.
  • Google tool scores remain poor despite successive fixes.

A common denominator is often a frontend developed over years on an older stack and surrounded by custom code.

At that point, further local fixes may cease to be a sound investment. It is worth checking whether rebuilding the presentation layer would be more justified.

Foundation

What Hyvä changes

Hyvä provides a simpler, lighter foundation for the Magento frontend.

Simpler development

Fewer layers and dependencies simplify subsequent changes. This can make the frontend easier to maintain and more predictable as it evolves.

Less overhead

Hyvä significantly reduces the overhead characteristic of Magento’s legacy frontend layer.

A better foundation

This provides a better basis for improving Core Web Vitals and the interface’s real-world speed.

It does not, however, guarantee a specific score-the outcome is also affected by the backend, images, third-party scripts, implementation and infrastructure.

A rebuild is a good opportunity to avoid carrying forward every legacy customisation.

Some will still be needed and must be adapted to Hyvä. Others can be simplified or removed entirely.

Technology boundaries

What Hyvä does not fix

Hyvä addresses problems in the frontend layer.

It will not speed up a slow database or fix faulty integrations, indexing issues, OpenSearch or unsuitable infrastructure.

If the backend takes a long time to generate a response, a lightweight frontend will still have to wait for it.

That is why, before recommending a rebuild, we determine where the actual limitation lies.

If the problem lies in the backend, the right starting point is Magento performance optimisation →

Scenarios

A new implementation or a rebuild of an existing Magento store

We work with Hyvä in two main scenarios.

Hyvä is our default choice for new Magento storefronts

This means the new platform is built from the outset on a frontend intended for continued development, rather than starting the project with a legacy technology layer.

The Magento backend can remain while the presentation layer is rebuilt

This removes the problematic frontend without requiring the entire platform to be rebuilt from scratch.

Such a project does, however, require deciding in advance which parts of the current solution are genuinely worth carrying over.

Legacy

We do not copy the old frontend one-to-one

A Hyvä rebuild should not mean automatically recreating every feature and customisation from the old store.

Before development begins, we determine:

  • what is actually being used,
  • which elements still have a business justification,
  • what can be simplified,
  • which solutions were created solely because of limitations in the previous frontend.

This prevents the new layer from starting life with debt inherited from the previous solution.

UX/UI

UX/UI can be part of the project

The client does not need to arrive with a finished design.

We can run the complete UX/UI process, prepare the interface design and then implement it with Hyvä.

We can also work with a design supplied by the client’s team or another agency.

Moving to Hyvä is often a good opportunity for a redesign, but a redesign is not a mandatory part of the technology rebuild.

Checkout

Hyvä and checkout

We treat checkout as part of the complete user experience, not as a separate product attached to the storefront.

The project can also include checkout UX and implementation of an appropriate checkout solution within the Hyvä ecosystem.

This is particularly important when the old store’s checkout is one of the areas that needs the most work.

Compatibility

Custom modules and compatibility

Changing the Magento frontend does not end with installing a new theme.

Every element with its own frontend layer must be checked:

  • Magento modules,
  • custom features,
  • payments,
  • shipping methods,
  • analytics,
  • marketing tools,
  • integrations that run in the browser.

Some extensions provide ready-made Hyvä compatibility. Others require adaptation, and in some cases replacing an old module with a simpler solution makes more sense.

That is why extension compatibility is considered during scope analysis, not only at the end of development.

Process

What a Hyvä project looks like

The scope can include analysis of an existing frontend or discovery for a new store, UX/UI, Hyvä development, adaptation of modules and custom features, checkout, testing, launch and stabilisation.

  1. 01

    Analysis

    Analysis of the existing frontend or discovery for a new store.

  2. 02

    UX/UI

    User experience and interface design.

  3. 03

    Development

    Frontend implementation with Hyvä.

  4. 04

    Adaptation

    Adaptation of modules and custom features.

  5. 05

    Checkout and testing

    Checkout implementation and testing of the complete solution.

  6. 06

    Launch

    Launch and stabilisation of the new frontend layer.

Not all work has to be performed sequentially. UX/UI, development of selected elements and integration work can partly run in parallel.

Project context

Hyvä as part of a broader change

A frontend rebuild is not always a standalone project.

Hyvä can be part of:

  • a new Magento implementation,
  • a redesign,
  • an optimisation project,
  • a project rescue,
  • a broader modernisation of an existing store.

What matters most is the problem we want to solve.

If the current frontend works well, is easy to maintain and only a cosmetic visual change is needed, replacing the technology may be an unnecessary expense.

Velocity

Why Velocity

Hyvä is our default direction for new Magento implementations.

When rebuilding existing stores, it is also important that our work is not limited to the frontend layer. We understand the Magento backend, database, OpenSearch, integrations and infrastructure.

This allows us to determine first whether the problem really lies in the frontend instead of assuming that Hyvä is the answer to every performance issue.

We can also remain responsible for the platform after launch and handle its continued development and maintenance.

The right direction

When Hyvä is not the right solution

Rescue Magento

If the entire platform is unstable, errors keep returning and its technical condition is difficult to determine, the first step may need to be taking over and stabilising the Magento project.

Rescue Magento →

A visual change

If the requirement is only a new look and the current frontend is healthy and maintainable, changing technology may not be economically justified. We also do not recommend Hyvä solely to achieve a particular PageSpeed score. First, we need to determine what is actually limiting the store.

Questions

FAQ

VLCT

If a significant part of the problem lies in the frontend layer, Hyvä can deliver a major improvement. It will not, however, fix a slow database, indexing, OpenSearch or integrations. Before recommending it, we determine where time is actually being lost.

VLCT

Hyvä provides a lighter frontend foundation and makes it easier to improve Core Web Vitals, but it does not guarantee a specific score. The bottleneck may still be the backend, images, third-party scripts, search engine or infrastructure.

VLCT

No. We can retain the current visual direction or treat the project as an opportunity for a redesign.

VLCT

Some have ready-made Hyvä compatibility, some require adaptation, and sometimes replacing an old extension with another solution makes more sense. We check this during scope analysis.

VLCT

Yes. If the backend and the rest of the architecture are in good condition, the existing platform can remain while the frontend layer is rebuilt.

VLCT

Yes. We can prepare the complete UX/UI or implement a design supplied by the client.

VLCT

Yes. We treat checkout as part of the frontend and purchasing journey, so it can be designed and implemented together with the rest of the Hyvä layer.

VLCT

Yes. It can also be used to build interfaces for B2B processes, including quick ordering, company accounts and other custom workflows. More: B2B e-commerce →