Process of development and technical support for projects after launch

Project development process

Launching the first version of a project doesn't mark the end of the work. A company's needs change as sales grow, new clients appear, internal processes shift, new campaigns launch, rebranding takes place, or the business enters new markets. That's why a working shop, app or system can go on being developed for months or years to come.

At Sopchy, we develop both projects we've built from scratch and existing solutions taken over from other software houses or developers. Development most often involves new features and integrations that weren't needed at the MVP stage or were deliberately left for later. Depending on the project, we also work on UX, performance, technology updates, process automation, migrations and technical issues.

Development work is carried out by Sopchy's own in-house team. We don't outsource development. Each client has a dedicated PM and can communicate with the team via the Sopchy panel, email and phone, and for larger projects we regularly discuss progress and upcoming decisions. This means project development isn't handed between random contractors, and the client has a single point of contact and always knows what's currently happening with their project.

1. We start with the goal, not the feature

The first question we ask when a new task comes in is: “Why do you want to do this?” The client doesn't need to know the technical solution. What matters more to us is understanding the problem or the outcome they want to achieve.

This matters because the same business goal can be reached in several different ways. The solution suggested by the client isn't always the one the business actually needs. So we first want to understand what problem needs solving and what should change once the work is done.

For example, a client might say: “We want to increase basket value, so we'd like to add the ability to create product bundles.”

In this case, we don't start by looking for a product-bundling module. First, we establish how the bundle sales should work, who they're aimed at, which products should be combined, and what business outcome the change is meant to deliver.

This means the company doesn't pay to implement a feature simply because it seems like a good idea. We first check whether it actually addresses the problem the business wants to solve.

Another example is a technical issue: “We changed the InPost delivery price, but the new price isn't showing up at checkout. Please check this.”

The client doesn't need to know whether the problem lies in the shop's configuration, the payment or delivery module, an integration, or the code itself. It's Sopchy's job to identify the cause.

This means the client doesn't have to diagnose the technology themselves or point the developer to the exact spot that needs changing. They can simply describe what isn't working, and the team finds out where the problem lies.

A similar situation applies to requests linked to market expansion: “We want to start selling in Lithuania and need a Lithuanian version along with support for the local currency.”

Only once we understand the goal can we determine which parts of the shop need to change and the best way to do it. This may involve not only translating the interface, but also currency, pricing, payments, delivery, tax, integrations and how information is presented.

Starting with the goal allows us to look at the change from the perspective of the whole process, rather than just a single feature.

2. We analyse the problem and choose the right solution

Once we know the goal, we work out how best to achieve it.

We don't automatically assume that the solution proposed by the client will be the best one. We check its impact on the existing system, the possibility of further development, dependencies on other parts of the project, and potential technical issues.

If the client points to a specific module, technology or way of implementing something, we check whether it fits the existing system and won't cause problems for future development.

If we know that a given module has technical issues, poor reviews, limitations, or could make future development of the shop more difficult, we let the client know. Where needed, we present alternative solutions and explain the differences between them.

This matters especially for shops and systems intended to run for many years. A solution that's quick and cheap to implement today may later increase the cost of further changes or tie the project to a technology that's difficult to keep up to date.

The decision belongs to the client, but it should be made on the basis of information about costs, possibilities, limitations and technical risk.

That's why development work at Sopchy isn't just about carrying out instructions. Our job is also to assess whether the proposed solution makes sense for the specific project and what its consequences might be for future development.

3. We check what we're dealing with

The scope of the analysis depends on the task.

For a small change, it's often enough to check the working system, reproduce the problem and establish what needs to change. There's no need to produce extensive documentation if the problem can be quickly verified directly in the project.

This helps keep the cost of preparatory work down for simple tasks. Not every change requires hours of analysis just because it's being carried out within an existing system.

For a larger change, we need to understand the existing solution in more detail. We may analyse documentation, code, configuration, integrations and how the system works. Reading documentation, testing and getting to know the project are all part of the work needed to properly define the scope.

In such cases, the analysis lets us check whether the assumed scope matches the actual state of the project. This reduces the risk of work starting on the basis of assumptions, only for additional dependencies or constraints to emerge during development.

New clients often come to Sopchy with an existing project whose documentation is limited or non-existent. In such situations, we don't require a full audit before starting the collaboration. We can begin with specific test tasks and get to know the project through actual work.

This matters to companies that want to quickly solve a specific problem but don't want to bear the cost of a full audit if it isn't needed to start the work.

For example, if the Omnibus mechanism isn't working in a PrestaShop store, we start by checking how it was implemented, where the problem lies and what needs to change. We don't assume from the outset that a full audit of the entire store is required.

If a client wants a separate technical audit carried out before further development begins, we can also do that.

4. Proof of concept before starting larger work

For new clients, the first analysis often takes place before the collaboration officially begins. This is needed when we first have to establish what kind of system we're dealing with and whether the assumed scope is technically feasible.

Such verification may involve analysing the existing solution, documentation, configuration, integrations or a specific technical problem. Its purpose is also to gather the information needed to prepare a realistic estimate.

This means the estimate for a larger task can be based on the actual state of the project, rather than solely on a description prepared without access to the system.

For larger changes, we can also prepare a proof of concept, prototype or visualisation of the solution. This allows us to test assumptions before starting full development.

This is particularly important when a wrong decision at the start of a project could mean writing a large amount of code that would later need to be changed or removed.

This applies, among other things, to key application mechanics, the customer panel, the product page, the hero section, or other elements whose functioning or presentation matter significantly to the project.

We can also use AI tools for rapid prototyping. AI helps us organise information more quickly, prepare feature descriptions, map out user journeys or create an initial visualisation of an idea. However, it doesn't replace the team's analysis or decisions. It's a tool that supports the work.

This allows us to move faster from idea to first version of the solution and to check earlier whether the assumptions need to change.

5. Small, medium and large changes require a different approach

Not every task requires the same process.

A small change might involve fixing an existing feature, a configuration issue or a bug. If its scope is clear, we can quickly verify it, estimate it and get started.

For such tasks, an extensive preparatory process could be disproportionate to the value of the change itself. That's why, for simple work, we try to move quickly from request to delivery.

A medium-sized change may require a more detailed analysis, checking several solutions, updating documentation, preparing a UX design or holding a technical consultation.

A large change may require a separate analysis, proof of concept, prototype, detailed specification, assessment of dependencies with other parts of the system, an estimate and planning of work across subsequent stages.

This means the level of analysis is matched to the actual risk and size of the task. We don't over-engineer the process for simple changes, but we also don't start large-scale development without checking key assumptions first.

For a business, this means a proportionate approach to the cost of preparing work. A simple fix doesn't require the same process as rebuilding a major part of the system.

6. We establish scope, priority and estimation

After the analysis, we determine exactly what needs to be done, how much work the change requires and which tasks depend on one another.

The client sets the business priority. However, if the order of work also results from technical dependencies, we point this out and recommend the appropriate sequence.

For example, a new feature may require an earlier change to how data is stored or the preparation of an API. In such a case, we don't carry out tasks purely in the order they were requested, but take technical dependencies into account.

This helps avoid a situation where completing one feature blocks further work or makes it necessary to rebuild elements that have already been completed.

For larger tasks, we prepare an estimate. The estimate defines the expected amount of work based on the information available at the planning stage. We don't treat it as a guarantee, since the actual state of the system may reveal additional dependencies.

If, during implementation, it turns out that the actual scope is larger than the initial analysis suggested, we inform the client of the difference and jointly agree on further action.

This allows the client to decide whether they want to continue with the additional work, change the scope, or split the task into further stages.

7. Development also begins with things set aside beyond the MVP

Not all features need to be built in the first version of the project.

When building the MVP, we jointly define the scope necessary to launch the solution. Further features can be noted down as elements for future development.

This approach makes it possible to launch the project without having to fund and implement all planned features at once. The company can start using the solution, and add further elements once a genuine need for them arises.

After launch, the client can therefore return to things that were previously set aside because they weren't essential for launching the project. These may include new store features, additional automations, B2B development, new integrations, further language versions, or changes to the purchasing process.

As the company grows, needs also arise that couldn't have been predicted at the MVP stage. Thanks to further development, the original scope doesn't have to be treated as fixed forever.

8. We update the project alongside changes in the company

Developing a system isn't just about adding new buttons and features.

A company may increase its campaign budget, enter a new market, start B2B sales, change how it handles orders, undergo a rebrand, change the store's UX, or start automating processes that were previously done manually by the team.

When that happens, the system needs to change too.

This matters because a solution that worked well at a smaller scale of operations doesn't always meet the company's needs a few years later. Technological development should stem from changes in how the company operates, not simply from a desire to keep adding new features.

For example, development may include increasing sales capabilities, additional cross-sell and up-sell features, automating the team's work, changing how products are presented, new language versions and currencies, integrations with further systems, or a redesign of the purchasing process.

That's why we don't treat an implementation as a closed project that stays unchanged for years to come. The system should evolve as the company's needs evolve.

9. We develop features and integrations

The most common scope of work after launch involves new features and integrations.

For an online shop, this might include: developing the purchasing process and checkout, B2B features, new ways of presenting and grouping products, expanding the admin panel, automating order handling, new payment and delivery methods, ERP integrations, BaseLinker integrations, warehouse integrations, payment provider integrations, courier company integrations, invoicing system integrations, and marketplace integrations.

Such integrations can reduce manual data re-entry between systems, cut down on errors and streamline the handling of orders, products, payments or deliveries. Their scope depends on which processes the company wants to automate and which systems it uses.

If a suitable module or API is available, we can use a ready-made solution. If it doesn't meet the project's requirements, we can prepare a bespoke module, feature or integration.

Choosing between a ready-made solution and bespoke development allows us to take into account both the cost of implementation and the specific requirements of the project, as well as its future development.

10. We don't develop a project at any cost

Sometimes analysis shows that the existing system doesn't allow the client's goal to be sensibly achieved.

An example would be a client wanting to implement extensive B2B features in an existing WooCommerce store, but the way the current shop was built makes it impossible to implement them properly.

In such a situation, we don't try to force features into the system if we know the solution would be unstable, difficult to maintain, or would limit further development.

This matters for the business, because an apparently quick implementation may later mean higher maintenance costs, further technical problems, or the need to rebuild work already done.

We first inform the client about the problem and check whether the same goal can be achieved another way. If a sensible alternative exists, we present it. If not, we say plainly that we won't take on the task within the current solution.

The same applies to situations where a project uses technology outside our expertise. We don't pretend we can carry out every task. If we're unable to provide a suitable solution, we let the client know.

For the client, this means clear information about the limits of Sopchy's responsibility and a lower risk of starting work that we're unable to complete properly.

11. We develop UX based on how the project is actually used

After launch, information emerges that can't always be predicted at the design stage.

It may turn out that users don't use a feature as intended, that a particular step in a process is too complicated, or that some information on the product page should be presented differently.

In such situations, we analyse how the current solution works together with the client, along with possible changes.

This means UX development can be based on how the shop actually performs, rather than solely on assumptions made before it launched.

If the change is more significant, we may prepare a prototype or visualisation before development begins. This allows the client to see what the new product page, customer panel, hero section or core app mechanic will look like before the full feature is built.

This reduces the risk of a full feature being coded, only for it to later turn out that the way it's presented or used needs significant changes.

12. We check the effect after deployment

Technical tests answer the question of whether a feature works. With larger changes, it's also important to ask whether it has solved the problem it was created to solve.

If the goal was to fix a technical bug, we check that the problem no longer occurs.

If the goal was to increase sales or basket value, we can analyse the effect together with the client, who monitors the business data. We can also analyse user behaviour, e.g. how the product page is used, and plan further changes on that basis.

This matters because deploying a feature doesn't in itself mean the business goal has been achieved. A feature may work correctly from a technical standpoint yet fail to bring about the expected change in customer behaviour.

Not every small change requires a separate measurement of its effect. With larger changes, however, it's worth checking not only that the feature has been deployed, but also that it has delivered the intended result.

13. We monitor how the project is running

Developing an existing system also involves responding to problems that arise after deployment.

Sopchy can monitor the availability of a service regardless of the technology it was built on.

If monitoring detects that the site is down, a notification can be sent to both the client and the Sopchy team at the same time. Once the service is restored, a further notification is sent confirming that it's working again.

Monitoring allows us to start responding without having to wait for the client or their users to notice the problem. In the case of an online shop, this has a direct impact on the availability of sales.

For example, if a shop starts returning a 500 error, monitoring flags the problem. We check the logs, identify the element causing the error, and, where possible, restore the shop's operation, for instance by disabling the problematic module. We then determine what needs to be fixed so the solution can safely go back into service.

If the problem persists for longer, we contact the client to confirm whether any work or changes are being carried out on their end. If the client asks us to start work straight away, we proceed with the investigation.

14. We respond quickly, but we don't make unrealistic promises

Technical problems can't always be resolved within minutes. However, we can begin investigating them straight away.

If a matter is urgent, we don't promise the client a specific resolution time we can't guarantee. Instead, we start checking the problem as quickly as possible and let the client know what we're doing and when we'll be able to provide further information.

This approach allows us to combine a quick response with realistic timeframes. The client knows the problem has been noticed and when to expect the next update, without being given a promise of a resolution time that can't yet be determined.

In standard work, we usually begin new tasks within 1–3 days. Urgent problems are treated as a priority.

During working hours, clients can contact us by phone. We usually reply to emails within a few minutes, and if a matter requires more detailed analysis, we let the client know when we'll come back with an answer.

15. We update the technology and respond to security changes

An older project may require updates to the platform, framework, library or other technological components.

Sopchy monitors information about available security patches for open source systems, so we can inform clients about the updates they need and make decisions about implementing them without waiting for an infection or failure to occur.

Regular updates matter not only for security reasons. They can also affect compatibility with the server, modules, integrations and future versions of the platform.

Before a major update, we check the state of the project and the dependencies between its components. If an update could cause problems with existing modules or integrations, we take this into account in the work plan.

This allows a company to plan for a risky change in advance, rather than reacting only once the old version stops working or a security issue appears.

In some cases, continuing to update an existing solution is not technically or economically justified. In such cases, we compare it with the possibility of rebuilding or migrating to a different solution.

16. We take over existing projects

Sopchy can take over the development of a project previously built by another software house or developer.

We don't require an existing project to have complete documentation. If documentation is available, we analyse it, as it can speed up our understanding of the system. If it's missing, we get to know the project through actual tasks.

This matters for companies that want to change their contractor but are worried that a lack of documentation will prevent further development. Incomplete documentation doesn't have to be an obstacle to starting cooperation.

For simple changes, we can quickly get to grips with a specific problem. For dedicated solutions, analysing the existing documentation, code and how the system works can be an important part of preparing for further work.

If the client needs a full picture of the project's technical condition, we can carry out a separate audit. However, this isn't required in every case.

We also agree with the client which problems and risks need to be addressed. If we notice something during the work that could hinder further development, we inform the client and agree whether they want us to deal with it.

17. We maintain ongoing documentation of changes

In an actively developed project, information about changes needs to stay up to date.

The project specification can be updated alongside subsequent changes. For larger changes, we describe the new features, dependencies and how the solution works.

We also keep earlier versions of the documentation so it's possible to check what the project originally looked like and what changes were introduced later.

This matters particularly for projects developed over many years or by several people. Up-to-date documentation reduces the risk of decisions being made based on outdated information, while the history of changes helps explain why certain solutions ended up in the system.

Not every minor fix requires updating the entire specification. We tailor the scope of documentation to the significance of the change.

We can also use AI to help organise information. For example, if the team has information about the system's features and user roles, AI can help turn this into structured user journeys or prepare an initial description of a mechanism. The material is still verified by the team.

18. Development environment and deployment

We carry out major changes on a development or staging environment, not directly on production.

This is especially important for shops and systems used by customers or employees, or that handle payments. An error introduced directly to production can affect sales or the functioning of existing features.

If the client doesn't have a suitable environment, we help set one up. The client can then check the solution, go through the prepared features and provide feedback before the production deployment.

Once it's approved, we agree on a deployment date.

For larger changes to online shops, we also take sales periods into account. We don't schedule migrations, technology changes or other risky work without considering campaigns, seasonality and the shop's importance to the client's sales.

This means the technical timeline is set with the company's business situation in mind, not just the developer's availability.

19. We test changes before deployment

Every change goes through testing appropriate to its scope.

The developer checks their own work, and for larger changes the solution may also be reviewed by another team member or during QA testing.

We don't just check the new feature on its own. For significant changes, we also test its impact on elements that might be affected by it.

In an online shop, this can mean checking the basket, checkout, payments, login, order placement, delivery handling, or other elements dependent on the change made.

This matters because modifying one element of an existing system can affect other features. Checking these dependencies reduces the risk that a new feature works correctly but ends up breaking part of the shop that was previously working.

The client mainly verifies the business functioning of the solution. They don't need to diagnose the code themselves or work out the technical cause of a problem.

20. We work in a way that keeps the client informed about what's happening with the project

For larger projects, we work in sprints and regularly discuss progress, usually during meetings held once a week.

The client has a dedicated PM and can comment on tasks in the Sopchy panel. Each task shows its status, the person responsible, comments and time spent.

This means the client doesn't have to ask separately about every change. They can check what's been reported, what the team is currently working on, and the status of a specific task.

For one-off or occasional changes, there's no need to organise regular meetings. In such cases, communication takes place around specific tasks.

The client should know whether a request has been noticed, who's handling it, what its status is, and when they can expect the next update.

21. We handle both small tasks and larger development work

We bill for support and project development on an hourly basis.

A client can request a single small change if they don't need an ongoing scope of work. They can also commission a larger stage of development if the project requires a greater number of changes.

We don't require a fixed subscription if the client has no need for one. A subscription is one of the available forms of cooperation, but in practice we often work in a model where the client submits tasks whenever they actually need them.

This model allows the scope of work to be adapted to the company's current needs. A client can commission a single fix, a few changes ahead of a specific campaign, or a larger stage of development, without having to maintain a fixed scope of work they don't currently need.

Thanks to this, cooperation can cover everything from single fixes to many months of project development.

22. Project development can go on for years

A project that works well doesn't need to be replaced with a new one just because the company is growing. It can be gradually adapted to new needs.

As a company grows, new needs may emerge, such as new features, greater automation, further integrations, UX changes, rebranding, new sales channels, entry into new markets, or a restructuring of internal processes.

Sopchy develops projects over many years. One example is Luxtrade, for whom we've carried out development work for over 4 years, mainly within the PrestaShop environment. The scope has included dedicated modules, integrations, rebranding, and mini-applications addressing the company's ongoing needs.

Over 90% of clients for whom we build projects also stay with us for further support and development. Cooperation with some clients has lasted 5–6 years or longer.

Project development therefore means more than just adding further features. It's a process of adapting technology to how the company, its customers, processes and sales methods change over time.

What does this approach to project development deliver?

Development should lead to a concrete change in how the company operates. Depending on the project, this might mean increased sales, a higher average order value, less manual work, process automation, improved UX, entry into a new market, integration of further systems, fewer errors, or technology prepared for further growth.

That's why, before starting any change, we return to its underlying goal. If a client wants to increase average order value, we look for a solution that can support that goal. If they want to enter a new market, we analyse the changes required in the system. If they report a bug, we look for its root cause rather than assuming in advance what needs to change.

This way of working allows us to develop an existing system in line with the company's real needs, rather than expanding it with features that don't solve a specific problem.

What do we most often work on as part of project development?

We develop stores based on PrestaShop, WooCommerce, Magento, Shopware and Shopify, as well as bespoke web applications. Our work can include adding and modifying store features, implementing B2B solutions, changing the purchasing process, extending the admin panel, adding ready-made modules and plugins, and creating our own bespoke PrestaShop and WooCommerce modules.

We also carry out integrations of stores with external systems, including ERP, BaseLinker, warehouse management systems, payment providers, courier companies, invoicing systems and marketplaces. If a system provides an API, we can use it to exchange data and automate processes. Where no ready-made integration exists, we build a bespoke solution tailored to the project's existing architecture.

We also develop the visual layer and the way the store is used. As part of a rebrand, we can implement a new design for an existing store, and where usability issues arise, we carry out a UX audit and implement the resulting changes. The scope of UX work may include, among other things, simplifying the purchasing process, improving navigation, product search, product pages, the basket and checkout, and changing the way information is presented to users.

Development can involve either a single feature or a larger overhaul of an existing store. We can work on a project previously created by Sopchy, or take over development of an existing solution from another software house or developer.

What matters most to us is that the scope of development stems from a real business problem or goal. This ensures that the system being developed supports sales, customer service and internal processes, rather than simply increasing the number of features without a specific purpose.