Where will your application be if your developers suddenly disappear?

Software development can be tricky.

Do you own your code, data, and infrastructure?
Do you know how to pass it all to another provider?
Can you do it within hours, days, weeks, or not at all?

It’s all great when the partnership is going well, communication is daily, and both sides are involved.
But you know what they say:

Hoping for the best, prepared for the worst, and unsurprised by anything in between.

Maya Angelou

It’s good to be prepared, for any circumstances. Too many times I’ve seen freelancers and agencies that didn’t want to share the code or tried to send ‘infrastructure’ and ‘database’ as a zip file to leave them alone.
The client was left without the product or the ability to finalize it with another agency.

Transparency is the key here, and Agile helped a lot. In most cases, you (the client) don’t have to wait months or years, before receiving the product you ordered, but not all agencies implement it.

Every software house or freelancer has its processes, flows of communication, management style, and so on.
Some of them will not support the transparency between the client and provider, and this is the point I’d like to cover in this article.

At the end of the article, you will find a scorecard to quickly judge, how transparent your developers are.

Enjoy!

Components of transparency in software development

1. Code
2. Application access
3. Infrastructure
4. Tasks
5. Roadmap
6. Communication
7. Team
8. Intellectual Property
9. Payments
10. Processes

In my opinion, each component can have 3 levels of transparency (or at least I assume this while writing these words, we will see how right I am)

Let’s dive in 🤿.

Access to the application code

As we all know, developers write code, which later produces the final application.

You don’t have to know how exactly it happens, but as the owner, it should be crucial for you to know where is the code, who owns it and what will happen when you stop working with the provider.

If you’d take only 1 thing from this article, please remember: own your code. Too many clients required our help, fighting with the current freelancer/agency, to get what they paid for.

Transparency levels:

1. You don’t have access to the code until the application is done, and you pay all the invoices.
2. You have access to the code, but it’s stored in the provider repository: you can be cut off at any point and have to manage backups on your own.
3. The code is in your repository (which you pay for) but at any point, you have access to the latest version of your application.

Access to the application environments

It is natural, that you get access to the production environment when it’s ready.
But what about the development/test/staging environments?
Can you test the application during the development, to see how it’s going, to give your feedback, or just to enjoy the process, you are paying for?

Transparency levels:

1. You don’t get access to the application until all the features are done, you only get access to the production environment.
2. You get access to the staging environment when all the features are implemented, and you have to start accepting them before the production release.
3. You get access to the development/test environment as soon as it has a sign-in page, and you can test, provide feedback and discuss everything with the provider all the time.

Infrastructure — where the application is released

These days, most of the applications are released to the cloud, so it’s not a matter of where the server is physically standing.

But it’s a matter of who owns the cloud (mobile store) account, where the application, its infrastructure and data are stored and who can kill and restore it within minutes.

How the app gets to the infrastructure is also important, but we will cover it in the processes component.

Transparency levels:

1. You have no idea where the application is released, you only get the link to the login page.
2. The application is released to the provider’s cloud. You know more or less what are the components and monthly costs for the infrastructure. You don’t have direct access to the cloud account.
3. You were asked and guided to set up your cloud account and provide access to the provider (which can be removed at any point). You get the infrastructure diagram and know exactly what services are used to handle your app. You are paying for the cloud and know exactly what the billing looks like.

Tasks

What are your developers working on, in what order, what are the priorities, what are the estimations, and are there any changes to the task’s scope, and requirements?

Finally, are there any bugs, issues, or change requests reported by the testers, which can influence the cost?

Dev teams usually work with the tasks and projects. It is the most effective and industry-standard way of building software.

Can you see it, or do you just get verbal reports from the project manager?

Transparency levels:

1. You don’t see how the tasks are described, what developers are currently working on, and what are the statuses. A project manager is your only point of contact, and you have to ask for all the updates.
2. You can see the spreadsheet with all the tasks, including the ones people are working on. The spreadsheet is not updated live, it doesn’t reflect the exact status of the task, and it has no bugs or comments from the testers team.
3. You have access to the project management tool, the same as used by the development team. You can see all the tasks, their description, statuses, comments, estimations, and requirements. You can see all the comments or bugs reported by the QA team. Furthermore, you collaborate with the developers to quickly adjust the priorities.

Roadmap

What is planned to be delivered in the upcoming weeks, or months? What does the timeline look like? Can you check it without asking the PM or developers?
We are talking about a period longer than one or two sprints ahead.

Although you know the overall scope and have discussed it with the provider before the start, the roadmap can change for many reasons. Some components are dependent, some work can be reused later etc. You can’t predict everything upfront, but how it is communicated to you is the key.

Transparency levels:

1. You get the information about the long-term deliverables from the PM or via email when you ask about it. It is not up-to-date and transparent at all.
2. You are informed about the roadmap changes periodically. You get the updates regularly over email, or on the live calls.
3. You can see the roadmap in the project management tool without the need to ask anyone. It’s up-to-date. You are asked if given changes are OK for you and know the reasons if the deliverables need to be changed.

Communication

How do you communicate with your developers? Is there a PM or you are talking to the devs? How often do you speak and is this enough? Can you provide feedback on the project, change the priorities, and ask for features during the process?

I think this is the point where my three transparency levels are a simplification because each project and client is different, but let’s try to list ways of communication, that can accumulate up to three levels.

• Communication with team representative over email
• Direct communication with the PM
• Direct communication with the whole team
• Regular live demo calls
• Direct access to the project management tool
• Ability to collaborate in the project management tool
• Being part of the task planning process
• Ability to provide feedback during the development process
• Retrospective calls to discuss what can be improved

Transparency levels:

1. 1–3 points
2. 4–6 points
3. 7–9 points

But as I said — this is a simplification. Not all the projects require all the forms of communication, you also might have your preferences, I’ll leave the judgement to you.

Team

Do you know who is working on your project and why? How is the team composed? Can you talk directly to every team member? How are you informed if there are changes in team members?

It might be less important when you hire a freelancer or a single developer, but when 3–10 people are working for you from the provider’s side — it’s good to understand who are you working with and what skills each team member has.

Transparency levels:

1. You don’t know. You only speak to the manager / PM / company owner, and people push your project forward.
2. You know the positions given developers have and the team composition of people assigned to your project. They might change without a warning, you still talk directly to the PM only.
3. You know all the team members working on your project, along with their titles and names. You can speak directly to each person. When the team member is about to change, you are informed about it upfront.

What’s optional, but can influence the transparency:

• 3-sided NDA between the client, company, and team member itself
• You can verify each team member either via the CV / LinkedIn profile check, or a dedicated recruitment process of your choice

Intellectual Property

Who has the code is one thing, but who can use it and how, is a different story. This again is one of these points, which can be missed during the negotiation or the contract review, but can be critical when the problems arise.

You have to make sure, that as soon as you pay for the work, you become the full owner of anything that was produced during the process.

Transparency levels:

1. The contract doesn’t specify the transfer of intellectual property rights. In practice, this means, you do not own your code and you can’t use it. But you will figure it out when trying to sell, or try to leave the current provider.
2. The intellectual property rights are transferred once, after finalizing the project. If for any reason the cooperation stops in the middle, the software provider might refuse to transfer the IP, which effectively means, you can’t use it until you find an agreement.
3. The contract states that all the IP created within a given period is transferred after the invoice is paid. With frequent invoicing, it effectively means, that in case of problems, the discussion is weeks of work, not the whole project.

Payments

It is important to specify, upfront, what you are paying for and when.
In the software development world, there are two main ways to pay for the software:

• Fixed price — scope and budget are fixed
• Time and material — scope and budget are flexible, you pay for the work done (hours, deliverables, or in other models)

You can also pay upfront, during the development or after the project is delivered.

Make sure the contract is fair for both sides (with many models, ‘fairness’ is changing, so I can’t specify this without the context).

Understand what you are paying for and when – most importantly, if you own the work results done until the payment.

Here again, the 3 transparency levels will be a simplification, but let’s try to show three extreme cases, but most of your experiences will be somewhere in between.

Transparency levels:

1. You pay 100% upfront. Then wait X months to see any results or get access to the app. When you start testing, most of the application looks and works differently than expected because the requirements did not cover everything. To get changes implemented, you need to extend the contract and pay again… Upfront. The cycle continues. (This is why software is not built in Waterfall any more)
2. You pay X% upfront, the rest after signing off the project. You have some time and number of repetitions to provide the feedback and developers will apply it within the budget. You have the leverage to negotiate resolving the bugs and issues until it’s finally done. (Very popular model for the websites’ development, or other smaller projects)
3. You pay periodically, for the work done during a given period. Usually, it’s a week / month or a sprint. With every payment, you accept the work done. You can flexibly decide about the priorities and apply feedback because contracts like this are typically based on the hours or deliverables.

Processes

Custom software is composed of custom code, written by the developers, along with third-party libraries and external solutions, not to reinvent the wheel.

But the software must run on some machines, servers, and clouds. To manage it all, often in the code we put the configuration files, which define where and how the code should be delivered.

On top of that, we configure the continuous integration, and continuous delivery (CI/CD) processes, so the developers don’t have to manually release the application each time they change something.

Processes like this can be directly in the code repository, manually configured in the cloud or externalized to other tools like GitHub actions / Codeship / Jenkins etc.

The development / DevOps team must describe it for you. In case of changing the provider, you know how to effectively run it on your own and don’t have to hire a detective, that will have to solve it from scratch.

Transparency levels:

1. You have no idea how and where the app is released. In case you break the relationship with the provider, you will get a zip file with the code and (if you are lucky) database schema. You have to figure out, with the new provider, how to set it up from scratch.
2. You get the diagrams of how and where the application is released. Maybe readme files are updated, and it’s described for the future developers, how to set it up from scratch in case of e.g. changing the cloud account.
3. What’s possible is configured in the code and stored in the code repository. It would be docker, GitHub actions, and database migrations like Liquibase scripts. Possibly, there is also a repository for Infrastructure as a Service (IaaS) where the cloud setup is described (but it’s not applicable always).
   Additionally, you have the diagrams, environments description and all the required documentation to easily start from scratch.

Software company transparency check

As promised, here is the spreadsheet, which you can copy and score your provider. Possibly in some areas, improvements are needed, perhaps you have a perfect 30/30 — stick to that company!

You are welcome to change the scoring / descriptions / definitions to match your approach to software development.

In that case, I’d be extremely interested in how you define transparency and what is missing in our calculations.

Summary

So, are you safe in case your developers disappear?

How many points, your provider gets?

Did you learn anything from this reading?

Happy to discuss or extend the scoring I proposed.