Choose a path for your project

Where are you starting?

You already have shared rules and prepared tools. Now choose the situation you are starting from. These are different paths, not more lessons to tick off.

• A new product — greenfield. Define the need, how it should work, and the first screens. Then build the first slice, using the team’s existing standards.
• A working system. First learn its behaviour, knowledge, and dependencies. Only then choose work with agents or modernization.

AI-first here means changing everyday work with help from agents. Legacy is a system whose constraints make development difficult. Older technology alone is not a reason to rewrite a product. Every path needs a person leading the task, someone to check the result, and time for a trial. A new project is also built alongside the team’s other responsibilities.

My five lessons from working with a software house

I gathered these conclusions while delivering a project with an external software house — a company that develops software — and preparing to take the work into our own team. They are useful both for a new project and when commissioning modernization or a legacy rewrite. Set the framework at the beginning, not only when you want to change the contractor.

1. Documentation can exist and still be hard to use

We had documentation, but its structure emerged ad hoc. Today I would agree the Confluence structure and required materials from day one: what we describe, who does it, and how we check that it is current at acceptance. Here I show the documentation structure and a file to use.

2. Tools and domains must be company-owned from day one

I later lost a lot of time moving GitHub, Jira, Miro, and other tools we used in the project. Today I would agree from the start that we work in company accounts and organizations for those services, with administration and billing on our side. The contractor receives the access needed to work.

This includes repositories, tasks and their history, documentation, boards, and Google Cloud (GCP) projects. Domains must also be registered to the company, including technical and test domains. A named person on our side must be able to manage them and ensure renewal. Simply inviting me to the contractor’s tool does not solve this.

Before starting, list the project assets and check each one: who owns it, who administers it, who pays, and who ensures continuity. For an existing system, mark dependencies on the contractor and agree how to put them in order before further development.

3. Agree the exit plan in the contract

An exit plan is the agreed way to end the collaboration and hand over the project. I want it in the contract from the beginning. Once the decision to take over the work has been made, it is harder. I do not assume a quick, accurate handover will then be as high a priority for the contractor as it is for me.

Agree what the team hands over, who does what on each side, when, and under what rules the takeover is supported. Include accounts, code, task history, documentation, domains, environments, knowledge, and open work. Also record who keeps the working application running until the takeover is confirmed.

Keep an updated list of task, owner, date, evidence, and acceptance condition. “We gave you the files” is not enough. My team must be able to run the application, deploy it in testing, and perform the agreed maintenance work. That checks the handover in practice, not just in a meeting.

4. Knowledge must move to your team during the work

Two technical people on our side helped preserve development continuity. At the time of this summary, though, we still depended on the contractor for DevOps — deployments and environment maintenance. That showed me that developing code independently does not mean maintaining the product independently.

Name the people who will take on the knowledge from the beginning. Have them go through a change, a deployment, and a response to a problem with the contractor; then have them do those activities themselves using the documentation. Agree the way to build this capability in advance: growing your own team, hiring, or an agreed transfer of people.

5. Billing hours does not mean key people are available

T&M (time and materials) bills working time and cost. I do not treat that model alone as a guarantee that the needed person will be available. In the agreement with the contractor, I want named key roles and people, their availability, and substitution rules. When someone leaves the project, it must be clear who takes over their knowledge and current tasks.

Check this before starting a collaboration

Take these five points into the conversation with the contractor. Open the real accounts, plan, documentation, and collaboration arrangements. Record each gap, its owner, and how it will be checked. Do not settle for an assurance that everything will be handed over at the end.

The file contains the “Working with an external contractor” section. Complete it with the team; do not create a second list if these arrangements already live in your plan.