How to choose a remote development partner: a due-diligence checklist

To choose a remote development partner, check five things before you sign: work you can verify yourself, ownership of the code and accounts on your side, a delivery process you can see, communication that fits your hours and language, and a contract that covers IP, personal data and exit. Then start with a small paid task. The checklist below turns each point into questions you can ask and evidence you can request.

1. A portfolio you can verify

Screenshots and logos prove little. Ask for things you can check without trusting the provider:

• Live products. URLs of sites and apps in production. Open them, use them on your phone, check that they load quickly and work.
• What exactly they did. "We built it" can mean the whole product or one landing page. Ask which parts, which stack, how long, and who else was involved.
• A reference you can call. One short conversation with a past client tells you more than any case study. Ask what went wrong and how it was handled.
• Code they own. Open-source work, their own products or a short technical exercise. Be wary of the opposite: a provider who shows you another client's private source code would do the same with yours.

The ShipFastDev portfolio follows that rule: it lists only live, public products.

2. Ownership: your code, your accounts

The most common outsourcing disaster is not bad code; it is not being able to get your code. Before any work starts:

• The repository lives in your GitHub, GitLab or Bitbucket organisation, and the provider is invited to it. If a repository already exists in their account, ask them to transfer it: on GitHub, issues, pull requests, wiki, stars and watchers move with a transferred repository, and old links redirect automatically.
• Hosting, domain, app store accounts, analytics and payment accounts are registered to your company, with the provider as a user.
• You can require two-factor authentication for everyone in your organisation; on GitHub, outside collaborators who don't use 2FA are removed from the organisation.
• The contract assigns the rights in the code to you on payment. Details in code ownership and IP when outsourcing.

3. A delivery process you can see

Ask the provider to describe a normal week, then ask for evidence. Useful questions, based on the delivery metrics used by DORA (change lead time, deployment frequency, failed deployment recovery time, change fail rate and rework rate):

• How often do you deploy to production for a client like us? Weekly is a good sign (see weekly releases with a remote developer).
• How long does a small change take from request to release?
• When a release breaks something, how do you find out and how fast do you roll back?
• Is there a staging environment? Automated tests? Who reviews code?
• How do you use AI coding tools, and how is their output reviewed? It is a fair question: in the 2025 Stack Overflow Developer Survey, 84% of respondents use or plan to use AI tools, 45.7% distrust their accuracy, and 66% cite "AI solutions that are almost right, but not quite" as a frustration.

Vague answers ("we follow agile best practices") are a warning. Concrete answers ("we merge through pull requests, deploy on Thursdays, and you get a changelog") are what you want.

4. Security basics

You do not need an audit for a small project, but you do need a shared vocabulary. NIST's Secure Software Development Framework (SP 800-218) was written partly so that software buyers can discuss secure development practices with suppliers. Ask how the provider handles secrets (never in the repository), dependency updates, access to production and the end of the engagement. France's cybersecurity agency ANSSI identifies loss of control, remote interventions and shared hosting as the main risks of outsourcing, and recommends that providers commit to a written security plan.

5. Personal data

If the provider touches personal data of your users, they act as a processor and you need a written processor agreement. The UK regulator's guidance lists what it must contain: processing only on your documented instructions, confidentiality, security measures, rules on sub-processors, help with data-subject requests and breaches, deletion or return of data at the end, and audits. The French regulator CNIL publishes a guide for processors with model clauses. If the provider is outside the EU, also check the transfer rules (see nearshore software development in Morocco for an example).

6. Communication

• Overlap hours: at least three or four shared working hours a day for a startup that changes priorities often.
• Language: the working language for calls and for written tickets.
• Cadence: a written weekly update (shipped, in progress, blocked) and a named person who answers.
• Response times: for normal requests and for production incidents.

7. Commercial terms and exit

Agree on the pricing model (see fixed price vs time and materials vs retainer), the notice period, and what the provider hands over when you part ways: repository, documentation, credentials rotated, data returned or deleted. Ending well is easier to negotiate before you start.

Red flags

• They want to keep the code in their own account "for now".
• Nothing in the portfolio can be opened or checked.
• A fixed price for a vague scope, with no change process.
• No production deployments until "the end of the project".
• The salesperson cannot tell you who will write the code.
• They show you another client's private code or data.
• They ask for admin access to everything on day one.

Start with a paid trial

Choose a real, small task (one to two weeks of work) with a clear definition of done, and pay for it. You will learn how the provider estimates, communicates, handles a question and ships. Combine it with the access plan in onboarding a remote developer.

Frequently asked questions

How do I vet a software development company?

Check live work you can open, call a past client, ask how they deploy and review code, confirm the repository and accounts will be yours, and run a small paid trial before a long commitment.

What should a software development contract include?

Scope or pricing model, IP assignment to you, confidentiality, a data processing agreement if personal data is involved, security commitments, notice period and handover obligations at the end.

Who should own the GitHub repository when outsourcing?

Your company. Create the organisation yourself and invite the provider. If the code already sits in their account, ask them to transfer the repository; history, issues and pull requests come with it.

What are the warning signs of a bad development partner?

Code kept in their account, an unverifiable portfolio, a fixed price for a vague scope, no deployments until the end, and an unwillingness to say who will do the work.

Sources

1. Transferring a repository, GitHub Docs, n.d.
2. Requiring two-factor authentication in your organization, GitHub Docs, n.d.
3. DORA's software delivery performance metrics, DORA, 2026-01
4. 2025 Developer Survey – AI, Stack Overflow, 2025-07
5. SP 800-218, Secure Software Development Framework (SSDF) Version 1.1, NIST, 2022-02
6. What needs to be included in the contract?, Information Commissioner's Office (ICO), n.d.
7. Guide du sous-traitant (RGPD), CNIL, 2017-09
8. Externalisation et sécurité des systèmes d'information : un guide pour maîtriser les risques, ANSSI, 2010-12