From first meeting to long-term development

It all starts with an initial call with our Sales & Partner Manager, Ebba Gyllin.

Above all, our goal here is to understand your business and your needs. This could involve a migration to Shopify, a brand new store, B2B, integrations, or a long-term partnership through one of our retainers.

We take in the information and documentation that already exists while simultaneously beginning to build our internal knowledge of your business, the existing solution, and the goals you want to achieve.

The first meeting is not about selling a pre-determined solution. It is about understanding the problem well enough to propose the right next steps.

The next step is normally our Discovery phase.

Discovery can be a single workshop or a longer series of workshops, depending on the scope and complexity of the project. For larger migrations, B2B solutions, or businesses with many integrations, we may need to go significantly deeper.

Together, we go through the areas that need to be clear before production begins. This could involve, for example, business processes, Shopify, ERP, PIM, WMS, payments, logistics, customer data, B2B flows, migration, SEO, and integrations.

Workshops can be conducted digitally, at one of our offices in Gothenburg or Malmö, or on-site at the customer's premises.

Technology is involved from the start

During Discovery, it is not just the Sales & Partner Manager who participates. A Solution Engineer from Stride is also involved.

Our Solution Engineers are full-stack developers who combine development with a greater responsibility for the solution and the customer's project. During Discovery, they help evaluate possibilities, identify technical dependencies, and develop the architecture for how the solution should be built.

This means that technical decisions are not left for a later stage. They are part of the discussion from the very beginning.

The same Solution Engineer then follows through into production. The person who has been involved and understood the business, the discussions, and the decisions during Discovery thus also becomes a central contact during implementation.

During Discovery, we continue to build our knowledge of the customer until we have a sufficient basis to define the solution.

For a migration or development project, this work culminates in a complete proposal that describes, among other things:

• technical requirements specification
• solution architecture
• project scope
• sprint planning
• delivery plan
• fixed price

This does not become a separate document that disappears once the project begins. The plan forms the basis for the quote and the agreement that the customer signs.

We simply try to do as much of the thinking as possible before development begins.

This results in a clearer scope, better cost control, and significantly fewer surprises during the course of the project.

We want the client to buy a solution, not hours.

That is why we work with fixed prices for our projects. The pricing is based on the scope and sprint plan that we have developed together during Discovery.

How many hours an individual developer spends on a specific feature is not what is interesting for the client. The important thing is that we deliver what we have agreed upon, with the right quality and within the agreed budget.

The thorough Discovery process is an important prerequisite for us to be able to work in that way.

Once the agreement is signed, production begins with a joint kickoff.

We bring together relevant stakeholders from the client and Stride. Together, we go through the project, sprint planning, division of responsibilities, and the delivery plan.

We clarify what materials and decisions we need from the client and set up the recurring meetings to be used during the project.

At the same time, the client gains access to Productive, the system where we manage our projects.

We want the client to be able to follow their project without having to wait for a status report.

In Productive, the project's tasks and deliverables are collected in one place. Among other things, the client can follow:

• each task in the project
• current status
• upcoming work
• sprints and delivery schedule
• the project's budget and progress against the agreed-upon financials
• communication regarding tasks and decisions

The client can also communicate directly with their Solution Engineer and other people working on the project.

This way, we work from the same project view instead of having information disappear between email threads, documents, and various internal systems.

All our employees are based in Sweden and speak Swedish.

For migrations and new builds, we typically hold at least one joint project meeting every week between the customer, the Solution Engineer, and relevant personnel from Stride.

The meetings usually take place via Teams and are used to review status, upcoming sprints, decisions, dependencies, and questions that need to be resolved.

This ensures that the customer remains closely involved in the project at all times and that decisions can be made continuously rather than piling up.

Even with a careful scope, almost everything changes during a project.

New ideas emerge. The business comes up with a feature they want to add. A need that did not exist during Discovery suddenly becomes relevant.

This is completely normal.

New requests are handled separately in Productive. There, the client can enter features or changes that fall outside the original scope and for which they would like a price.

We review the requirement and return with a fixed price.

If the client approves the price, the work is added to the project and scheduled along with other deliverables. In other words, the client does not need to approve ongoing consulting hours but knows what the change costs before work begins.

We do not develop directly in the customer's live theme.

Work is carried out in separate development and sub-themes, and our code is version-controlled in GitHub. This gives us control over changes, version history, and the ability to review code before it is pushed forward.

We work according to our established QA processes, and code is reviewed before it goes live.

This reduces the risk of ongoing development affecting the existing store and makes it possible to test changes thoroughly before they reach the customer's visitors.

When a new project approaches launch, an extensive UAT period – User Acceptance Testing begins.

Here, the solution is tested systematically by both Stride and the client.

We work with prepared test documentation and go through functions, flows, and key scenarios before the solution is approved for launch.

It is not just about verifying that a page looks correct. We want to ensure that the complete solution works in reality – from the customer journey and checkout to integrations and internal workflows.

Only when the tests are completed and the solution is approved do we plan the final launch.

We support the customer all the way until the new solution is live.

During a migration, the existing store remains active and operational throughout the project. The new solution is developed and tested in parallel, replacing the old one only once we are both ready to execute the launch.

Ahead of the move, we plan the cutover, data migration, integrations, and other dependencies that need to be managed during the transition.

We also assist with redirects and SEO work related to the migration, ensuring that, for example, existing URLs and organic visibility are handled as part of the move.

The goal is for the transition itself to be as controlled as possible.