What the project development process looks like at Sopchy

Needs analysis and getting to know the business

We begin every project by getting to know the company and how it operates. In our initial conversations, we want to understand what the client does, who their customers are, how individual teams work and what solutions they currently use. We also ask about the problems the company wants to solve, the most time-consuming tasks and the processes that need improving or automating.

This information directly shapes how the project is designed. Features, permissions, user journeys, integrations and how the system works all stem from the company's real needs, rather than from the assumption that every project should follow the same template.

At this stage, the client doesn't need to know which technology or specific solution will work best. We first define the need and the expected outcome, and only then choose how to deliver it. The client's knowledge of their business, processes and users is just as important as the team's technical expertise. Combining these two perspectives allows us to design a solution that fits the way the company actually operates.

If we're working on an existing solution, we analyse its current state. We check what's working well, which elements the client wants to keep, and which they want to drop. We review the technologies used, existing integrations and any available technical documentation. If documentation is missing, we get to know the solution from a technical standpoint to determine the scope of work required.

This doesn't always mean carrying out a full audit before starting the collaboration. For simpler changes, we may get to know the system while working on a specific task. For larger or riskier work, we scale up the scope of analysis accordingly. This approach avoids the cost of a broad analysis where it isn't needed, while also reducing the risk of starting major work without checking key dependencies.

1. Specification

The next stage is preparing the project specification. The client may provide their own documentation, but often we only receive a general brief. We treat this as a starting point and add the information needed to design and implement the solution.

The specification translates business needs into concrete system behaviour. It describes user journeys, system features, roles and permissions, and the scope of access for each type of user. We define who can perform specific actions, what information they can see, and how individual processes should run.

We also describe integrations in detail. We establish which systems the project will communicate with, what data will be exchanged, in which direction the data will flow, and where each piece of information will be managed.

For an e-commerce project, this might mean planning communication between the shop and an ERP system, BaseLinker, a warehouse management system, a payment provider, a courier company, an invoicing system or a marketplace. The scope of integrations is defined based on how the specific company operates, not simply on the technical connections that are available.

At this stage, we also set priorities. We determine which features are essential for launching the first version of the project, known as the MVP, and which can be delivered later and added to the backlog.

This separation of features is particularly important when the project needs to launch within a specific timeframe or budget. It allows work to begin with the scope needed for the project to function, rather than delaying launch until every planned feature has been built.

The specification also helps us identify missing information, dependencies between features and factors that could affect time and cost earlier on. Changing assumptions at the documentation stage is usually much easier than changing the solution after development has begun, the database has changed, or integrations have already been built.

Based on the specification, we also estimate the time needed to deliver each element. The estimate relates to the scope described, so the more precisely the requirements are defined, the easier it is to determine the amount of work involved.

For the client, this means greater predictability before development begins. It's clear what needs to be built, how it should work, which systems will be connected, and which features will be delivered first.

2. Choosing the technology

We choose the technology and implementation approach once we understand the project's requirements. We don't assume that every project should be built on the same platform.

If an existing solution meets the requirements, we can use it and extend it with the needed features. If it doesn't meet the project's requirements, we can build a dedicated solution instead.

Depending on the needs, we might work on an existing system, extend an open-source platform, build a dedicated module, or create a solution from scratch. When choosing the approach, we take into account factors such as the scope of features, potential for further development, required integrations, maintenance needs and the anticipated amount of work.

The choice of technology also matters for the project's future development. A solution that meets the requirements of the first version but makes later changes difficult can generate additional costs at later stages. That's why, when choosing an approach, we consider not only the current requirements but also the planned direction of development.

One example is the Trend Glass project, where a B2B shop was migrated from a SaaS solution to an open-source platform. As part of the project, we rebuilt key processes and administrative features, integrations with external systems, and functionality available to customers.

In this case, the platform change was driven by the project's needs and the scope of features that had to be preserved and further developed. This shows that choosing the technology is part of the design process, rather than a decision made independently of the company's needs.

3. Prototypes, UX and design

For the most important or more complex features, we prepare prototypes and mock-ups. These allow us to see how a process will work before development begins. This means we can check the user's next steps, how information is presented, and the actions available to them.

A prototype also allows us to validate an idea early on. If a particular path turns out to be unclear, requires too many steps, or doesn't meet users' needs, we can change it at the design stage, without touching the finished code.

We also use AI-based tools when preparing prototypes. In some cases, these allow us to prepare and validate initial versions of a solution more quickly, with less effort. We treat AI as a tool that supports the design process, not one that replaces the analysis of needs, design expertise, or decisions about how the system works.

We keep track of developments in AI tools and use them where they can genuinely speed up the work or reduce its cost, particularly at the stage of drafting concepts, organising information, and creating initial prototypes.

Where we're responsible for design within a project, we also prepare an initial visual standard and a direction for the interface design. Subsequent views of the project are built on this basis.

Key elements of the design are approved before implementation begins. This means the way a feature works, the user journey, or the look of the interface can be changed at the specification or prototype stage, before a change would require modifying the code, database or integrations.

We treat the creation of a design as a collaboration between two parties. Sopchy brings knowledge of technologies, implementation possibilities and the consequences of particular decisions, while the client brings knowledge of their company, users and processes. On this basis, we jointly agree how the project will work. The client approves the key assumptions, look and functionality before development work begins.

4. Schedule and delivery

Once the scope, functionality and look of the project have been approved, we prepare a schedule. We set out the order in which stages will be delivered, the planned timeframe for the work, and the people responsible for each task.

We also take into account tasks that need to be completed by the client or by other parties involved in the project. These might include preparing translations, content, legal materials, graphics, product data, or data required for integrations.

Taking these dependencies into account is important, since some development work cannot be completed without data or decisions that rest with the client or an external supplier. Identifying such elements early allows us to plan the order of work better and reduce delays.

We then break each stage down into specific tasks and begin development work. We deliver larger projects in sprints, and we present the results of each stage to the client during regular meetings.

The client approves the functionality and scope of the project before development begins. Once individual features have been built, the client can check whether they've been delivered in line with the previously approved specification.

Breaking the project down into specific tasks allows us to monitor progress and spot more quickly if delivering a given element requires additional discussion, data, or decisions.

5. Changes during delivery

The assumptions behind a project can also change while work is underway. This might result from a change in the company's needs, the emergence of new information, or a decision to add a feature that wasn't originally part of the scope.

If the client wants to add a new feature or modify a previously agreed element, we work out the expected time needed to deliver the change and its impact on the remaining work and the schedule.

The client then decides whether the change is needed within the current stage, or whether it can be moved to a later stage of development and added to the backlog.

This approach means decisions about changes can be made based on their actual impact on the project. The client knows the expected additional effort involved and can decide whether to spend the time and budget allocated to the current stage on the change, or to deliver it later.

As a result, new tasks aren't simply added to the project without considering their impact on the previously agreed scope. Change remains part of a consciously managed project scope.

6. Testing and deployment

Before launch, the project is tested internally. Developers check the features that have been built, and the work is reviewed by other team members. Depending on the project, functional and manual testing by QA is also carried out.

We test not only the new feature itself, but also its impact on the elements it's connected to. In an online shop, this may mean checking the basket, the checkout process, payments, delivery, login, or other functions affected by the change.

This is important because a single feature that works correctly on its own may still affect other parts of the system. Testing helps uncover such dependencies before the change is published to users.

The client is not responsible for the technical testing of the implementation. Their role is primarily to check whether the finished feature works according to the specification and the agreed way of operating, and whether it meets business needs.

Work is carried out on a development environment. Depending on the project's needs, we also prepare a staging environment, where the solution can be checked before it goes live.

Separating the development, staging and production environments allows changes to be tested before they're published to end users. This is particularly important for shops and systems used by customers or employees, where an unverified change could affect sales or the day-to-day running of the business.

Once work and testing are complete, we deploy the project to the production environment. For larger deployments, we agree the publication date taking into account the company's operations, sales campaigns, seasonality, and the significance of the change for users.

Where needed, we also help prepare the environment required to launch the project.

After deployment, we train the client's team and hand over the necessary access. Where needed, we also prepare PDF or video instructions that can be used when onboarding further team members.

Which companies do we work with?

Sopchy mainly delivers projects for medium-sized companies, for whom digital solutions and e-commerce have a direct impact on the business.

Our clients include companies for whom the online shop is an important or main sales channel. These are usually companies handling anywhere from several hundred to several thousand transactions a month.

At this scale, an online shop is no longer just a page presenting products. How it works affects sales, customer service, teams' work, order fulfilment, inventory management, and communication with other systems.

Because of this, projects for such companies often involve not only building or changing the shop itself, but also integrations, process automation, the development of B2B features, redesigning the purchasing process, platform migration, or the ongoing development of an existing solution.

Summary

The project development process is designed to reduce the risk of costly changes and misunderstandings during delivery. We start by getting to know your company and how it operates, then translate business needs into a concrete specification, choose the right approach to delivery, prepare prototypes, and only then begin development.

Each stage has a specific purpose. Analysis helps us understand the problem and its dependencies, the specification organises the scope, features and integrations, technology selection allows us to pick the approach best suited to the project, prototypes make it possible to validate ideas early on, and testing reduces the risk of issues after launch.

For the client, this means being able to make decisions based on concrete information before the full scope of work is carried out. You know what needs to be delivered, what the dependencies are, which elements are priorities, and where additional requirements might arise.

The project development process ends with the launch of the solution. Further development, updates, optimisation and ongoing support can be carried out as part of separate collaboration arrangements.