Prepare the conditions that allow the work to continue.
Software becomes part of how your business works. Your teams invest time in it, your data moves through it and your business rules take shape within it. The investment goes well beyond the first screens delivered.
At Progymédia, we want that work to keep serving your business. This requires technical decisions and a clear conversation about code, licences, access and maintenance. The answers for a particular project need to be confirmed in the terms agreed with you.
Identify the different parts of the project.
A website or application can combine development specific to your business, shared platform mechanisms and third-party services or libraries. These parts serve different roles. It helps to name them before discussing what you will be able to keep or change.
When discussing Boutik, we distinguish project-specific work from the shared foundation and its dependencies. The exact scope needs to be described. A general statement about ownership of a website does not establish the terms for every component.
Ask what you will be able to use and modify.
Who holds the rights to project-specific development? Which parts are accessible? Under what licence is the shared platform used? Can another team work on it, and under which conditions? These questions help explain what the proposed solution actually includes.
Code access, permission to use it and a commitment to supply new versions are separate matters. The relevant version, handover process and conditions for continuing the work need to be defined. We prefer to discuss them explicitly rather than leave each person to draw their own conclusions.
Consider what a team would need to continue.
Code alone does not explain how a system works. Understanding an application also requires knowledge of its connections, data model, important rules and deployment process. Documentation proportionate to the project helps both the current team and one that might take over.
The discussion can include code repositories, environments, administrative access, backup procedures and data handover. Who is responsible for them? In what format will information be available? What work would be needed to prepare a transition? These details need to reflect the circumstances of the project.
Separate a usable version from its ongoing maintenance.
Keeping a version of an application and maintaining it over time call for different arrangements. An external service can change, an ERP connection can evolve or a security fix can become necessary. Continuity also involves deciding how those changes will be monitored and addressed.
We encourage practical questions: who monitors dependencies, who evaluates updates and how are interventions planned? Hosting, support, fixes and further development each need a clear scope. Their availability and costs cannot be inferred simply from receiving the code.
Make technical choices that help future work.
Our modular approach separates shared mechanisms, adaptation to business systems and the interface used by your teams or customers. This organization helps identify which parts should be configured, extended or replaced as needs change.
It still requires maintenance and an understanding of how the components relate. A change in one area can affect another. Knowing those connections, maintaining useful checks and recording important decisions helps the project evolve thoughtfully.
Put continuity on the agenda from the start.
You do not need to become a licensing specialist to ask useful questions. You can explain what you want to preserve: your business rules, your data, your ability to develop the website further or the option to work with a different team in the future. These are concrete goals to address in the project.
We can then examine the technical answers and applicable terms, and identify anything that needs clarification. A lasting working relationship benefits from making these subjects understandable. Your team can see what is planned, what remains to be decided and how the work can continue.
Points to clarify together
✓ The project-specific, shared and third-party components.
✓ The rights, licences and access applicable to each.
✓ The documentation, data and environments needed for a handover.
✓ The scope of hosting, maintenance and updates.
✓ The conditions and work involved if another team takes over.
