Software development and maintenance

Yes. We review code, documentation, environments and access. We establish what can be run and tested, identify dependencies and find gaps that need addressing before taking responsibility. This informs the first stage of work.

No. Many applications can be developed within their current architecture. If we find constraints that need modernization, we explain them and propose a separate scope. Decisions account for costs, business needs and disruption risks.

We agree team capacity, budget and the order of work. Requests needing a response are distinguished from planned development. Regular reviews allow priorities to change with a clear understanding of the effect on schedules and other tasks.

Support hours, reporting channels and expected response times are agreed before work starts. Round-the-clock coverage is not assumed. Availability and incident requirements determine the appropriate contractual scope.

We identify critical journeys and cover them with tests suited to the system. Changes are checked in a test environment and code is reviewed. Deployments include a rollback approach, with validation matched to the impact of each change.

Yes. We agree responsibilities, repository workflows, code reviews and releases. We document application knowledge so that the collaboration does not depend solely on individual people.

We agree a handover of code, documentation, dependencies and deployment instructions. We organize access and outstanding work, and can arrange knowledge transfer sessions for the team taking over the application.