Quality & Safety

Reliable delivery requires structure

We work with business-critical e-commerce solutions, integrations, and customer data. For us, quality and security are therefore not something added at the end of a project – they are part of how we work from the start.

We have clear procedures for permissions, code, documentation, quality assurance, and project management. The goal is simple: our clients should feel confident in both the solution we build and how we work along the way.

In practice

Structure that reduces risk.

2FA on all core systems

Password management

GitHub versioning

Code review

GDPR / DPA

Transparent project management

01

Secure access and permissions

We use two-factor authentication on the systems and services we work in and manage passwords and other credentials through a central password management system.

Access to customer systems must be personal and limited to the individuals who need it for their work. We avoid shared accounts and work with clear permissions where the platform supports it.

When an assignment changes or a person no longer requires access, the permission must also be removed.

We view access to customers' Shopify stores, business systems, integrations, and other services as a matter of trust – not as an administrative detail.

02

Personal data and GDPR

When our work involves Stride processing personal data for a client, we work with data processor agreements.

The agreements clarify responsibilities, processing, and how personal data may be handled within the scope of the assignment.

At the same time, we strive to minimize the data we need to access. Access to personal data must have a clear purpose and be relevant to the work we perform.

03

Version control with GitHub

The code we develop is managed through GitHub.

It provides us with version history and traceability of changes, and enables us to work in a structured manner with branches, pull requests, and reviews before code is moved to production.

If something needs to be analyzed in retrospect, we can see what was changed, when it was changed, and which code belonged to each specific change.

This creates a significantly safer development process than working directly in a production environment without version control.

04

Code is reviewed before going live

Not all code should go directly from developer to production.

We work according to defined QA processes where changes are reviewed and quality-assured before release. Our Head of Development has overall responsibility for technical quality and reviews code and solutions before major changes go live.

Depending on the project, quality assurance includes functionality, responsiveness, compatibility, performance, accessibility, and ensuring the implementation follows our technical standard.

We strive to catch issues before the client or end customer does.

05

Controlled releases

A release must be planned and traceable.

We work with clear workflows between development, testing, and production, and we avoid making uncontrolled changes directly in a live store as much as possible.

For major launches and changes, we also plan dependencies, testing, and the transition to production itself.

For migrations and other business-critical launches, we work with specific launch and cutover plans where responsibilities and sequences are defined in advance.

06

Transparency throughout the project

All our projects are managed in Productive.

This is where we gather tasks, responsibilities, estimates, reported time, budgets, and project progress, among other things. The client gains insight into the project and can track both the work and the finances on an ongoing basis.

We don't want a client to have to wait for a monthly report to understand how a project is progressing.

This transparency also makes it possible to detect deviations early and make decisions before a minor change becomes a major problem.

07

Documentation as part of the delivery

Good code is not enough if no one understands the solution afterwards.

That is why we document important technical decisions, integrations, and solutions when the project requires it. For more complex implementations, we also work with technical requirement specifications, solution architecture, and documented dependencies before development begins.

This makes the solution easier to maintain – regardless of whether the next change is made by us or by someone else.

08

Standard before custom solution

Quality and security are also about not building more than is necessary.

We primarily use Shopify's standard functionality and established solutions before choosing to develop custom features. Fewer custom solutions normally mean fewer dependencies, less technical debt, and a solution that is easier to understand and maintain.

When we build custom solutions, there must be a clear reason for doing so.

09

Security is an ongoing process

No technical environment is ever finished from a security perspective.

Platforms change, new risks emerge, and working methods need to evolve. Therefore, we view security and quality as a continuous effort rather than a one-time check before launch.

We build our processes to reduce risk, create traceability, and make it clear who is responsible for what.

For us, quality is about building the right way. Safety is about doing it in a way that our customers can feel secure with.