Want to know if a software development vendor is prepared? Ask them where your code will live.

If you’re short-listing vendors for a software development project, your due diligence should involve asking questions around code management and connectivity.

  • Where will your code live?
  • How easy will it be for you to access the code?
  • How prepared, secure, and professional is the vendor’s work environment?
  • Do you have options? Can they walk you through the pros and cons of different models for code management?

How your vendor handles your code is a good representation of how they’ll handle the business relationship. Is your vendor prepared to make things comfortable for you?

Whether you plan to use a vendor’s infrastructure or your own, evaluating the dev/test environment, code quality resources, communication tools, and security processes is a great way to gauge their preparedness. Do they use static code analysis tools? If yes, which ones and why? What project management or electronic board tools do they use today? How flexible are they in learning your tools if they don’t use the same ones you do?

Ideally your vendor will adopt the tools, security requirements, and preferences of your team and organization. Learning how flexible and open they are is indicative of what type of partner they will be. Will you always have access to your code, your IP? Can you pull it anytime you need it? Are they open to working in your environment? Do they have their own environment that is ready for you to use?

The best vendors will have options and you will be able to pick the one that works best for you. At Integrant the breadth and depth of our resources allows us to support multiple code management and connectivity environments (details here). Following are a few models we offer and the pros and cons of each.

Code lives in Integrant’s environment

In this scenario you can leverage our tools for:

  • Continuous code quality inspection platform (we use SonarQube – here’s why)
  • Source code management
  • Reporting and dashboards
  • Requirements and project management
  • Automated builds, continuous integration, auto deployment, release management
  • Test management

You might choose this option if you’re a startup with few or no software dev/test related resources. Or you might be part of a large company with a robust IT department and it might be easier for you to have us handle source code than to go through the sometimes cumbersome, time-consuming process of getting us access to your on-site environment.


  • Start right away. Avoid setting up a middle-man repository or jumping through internal hoops to get your Integrant team access to your environment.
  • Avoid investing in tools and training associated with code management and quality.


  • With this option you may have concerns about the security of your code. Ask your vendor about their security processes and certifications. For example, Integrant is SOC2 Type 2 certified. There are also many methods to ensure your data never leaves your hands without compromising the viability of your dev/test environment.
  • You might feel your code is vulnerable to being “held hostage.” Verify you have 24/7 access to your code. At Integrant we address code ownership concerns in several ways:
    • Our contract with our clients states clearly that all code is the property of the client. (A related topic is code ownership or IP protection. Here’s some info that will help you guarantee legal protection in your vendor relationship.)
    • Due to our internal process and tools, the client has 24/7 access to the environment and can download current code on a daily basis.

Code lives in a hybrid environment

This option provides access to all the tools above, but the code is parked in the cloud via GitHub, BitBucket, or a similar third-party repository. You assign your Integrant team usernames and passwords with appropriate permissions.


  • You have access to our tools like SonarQube (static code analysis and more).
  • If you own the GitHub repository you have full access and control over your code. You can give others read-only access and they can’t change the code directly except through pull requests.


  • Like the first option (where code lives in Integrant’s environment), you may still have concerns surrounding continuity or security associated with a third-party repository.

Code lives in your environment

In this situation your Integrant team works within your environment using your tools. Your Integrant team can:

  • Access your servers using a client-based VPN solution with appropriate access to only systems that are needed, or
  • Create code and/or builds locally and then move the appropriate files into a secure shared landing zone for pick up by you as needed.


  • If you have a robust internal environment, this option allows you to leverage it. If your vendor uses the same or similar tools on their end, there should be no learning curve attached to working in your environment. This is one reason why we advise you to learn about the vendor’s environment even if you plan to use yours.
  • This option accommodates any internal security protocol requiring that all source code reside within your walls. Your IT team will have full control and the ability to monitor and audit all traffic.


  • There could be hurdles and red tape attached to getting a vendor access to your environment.
  • If you’re a startup or lack the “latest and greatest” in your internal environment, you may not have access to tools like static code analysis, continuous integration, continuous delivery, etc.


Evaluating a potential vendor’s answers to your code management and connectivity questions will give you a feel for the relationship to come. A vendor’s robust infrastructure and internal environment are an indicator of preparedness, professionalism, trustworthiness, and flexibility.

facebook twitter linkdin