The Short Answers

Four Questions, Answered Before the Detail

If you read nothing else on this page, read this row. The sections below explain why each answer is what it is.

Who employs them?

We do. Developers are engaged through JS Devs, so there is no employment relationship between you and the developer and no payroll obligation on your side.

Who owns the code?

You do. Rights in work produced for you vest in you, and the assignment runs through our agreement with the developer as well as our agreement with you.

Will you sign an NDA?

Yes, yours or ours, mutual, before you describe the system in detail. The developer is bound too, not just the company that introduced them.

Can I hire them permanently?

Yes, by agreement. There is a direct-hire clause, it is negotiable, and we would rather settle a fair fee than lose the relationship over it.

A developer reviewing source code and a signed document side by side on a desk

The Contracting Chain

Two Agreements, Not One

There are two contracts in any engagement and it is worth knowing which is which. The first is between you and JS Devs: it sets the rate, the hours, the notice, the replacement window and the non-solicitation position. The second is between JS Devs and the developer: it covers their engagement with us, their confidentiality obligations, and the assignment of intellectual property in work they produce.

You never sign anything with the developer directly, and that is deliberate. It is what keeps the arrangement clean: no employment relationship arises between you and them, you have no payroll or statutory obligations in their country, and ending an engagement is a matter of contractual notice rather than a termination process.

The part people miss is that the second contract is what makes the first one work. A staffing company can promise you ownership of the code all it likes; if its own agreement with the developer does not assign those rights, the promise has a hole in it. Ours does assign them, which is why the chain matters more than the headline.

Intellectual Property

What You Own, and the Three Things You Do Not

The general position is simple. The exceptions are the ordinary ones, and any staffing or development company that does not mention them is either not thinking about it or hoping you will not ask.

Yours

Everything Built for You

Source code, configuration, infrastructure definitions, database schemas, test suites, documentation and designs produced as part of the engagement. Rights vest in you, and they vest as the work is created rather than waiting on a final payment, because there is no final payment in an ongoing staffing engagement to wait for.

Not ours to give

Open-Source Components

A React application pulls in dependencies and those keep their own licences. Nobody can assign you rights over code somebody else wrote and released under their own terms. What we can do is keep the choices sane — permissive, well-maintained libraries rather than something with a licence that becomes your legal department’s problem later.

Stays with them

General Skill and Technique

A developer who learns your domain does not have to forget how to write a queue consumer afterwards. General knowledge, technique and experience travel with the person. What does not travel is your code, your data, your architecture documents and anything specific to your business, all of which are covered by confidentiality.

Always was yours

Everything You Supplied

Your existing codebase, your designs, your content, your data and your trade marks were yours before the engagement and remain yours throughout it. A developer working on them acquires no rights in them, and nothing in our agreement attempts to claim a licence over your material beyond what is needed to do the work you asked for.

NDAs

Confidentiality, in Both Directions

Most NDA conversations are slower than they need to be because nobody says what they want. Here is what we will sign, how to get it done quickly, and what the document honestly does and does not achieve.

1

Ask, Before the Detail

Say so in your first message, or tick nothing and simply write “NDA first”. Assume that first email is not yet covered, so keep it general — a role and a stack is enough to start, and it reveals nothing you would mind a competitor reading.

2

Yours or Ours

If your legal team has a standard mutual NDA, send it and we will review it rather than insisting on our own paper. If you would rather not involve lawyers for an introductory conversation, ask us for a mutual document and we will provide one.

3

It Binds the Developer Too

An NDA with a staffing company that does not reach the person reading your code is close to useless. Developers placed on your engagement are under confidentiality obligations, so the duty follows the access. Where your document requires the individual to sign directly, that can be arranged.

4

It Survives the Engagement

Confidentiality does not expire when the developer rolls off. It continues afterwards, and it covers what they saw as well as what they wrote — your architecture, your customer list, your incident history and the commercial information they were exposed to in standups.

What It Genuinely Protects

Specific, non-public information: your codebase and architecture, credentials and infrastructure detail, customer and pricing data, unreleased plans, and the contents of conversations about any of it. If that information is disclosed or misused, the document gives you a contractual route to do something about it, and it makes the obligation unambiguous for everyone who signed.

Where People Overestimate It

An NDA does not stop somebody having a similar idea, does not make a general concept proprietary, and does not cover information that was already public or that you disclosed elsewhere without protection. It is also not a substitute for access control: the strongest confidentiality clause in the world is weaker than not granting production credentials that the role never needed.

Non-Solicitation and Direct Hire

The Clause Everybody Worries About, Written Fairly

In staffing this is the clause that actually matters, and the one most often written to be discovered rather than read. So here it is in advance.

What the Restriction Says

During an engagement, and for an agreed period after it ends, you agree not to engage or employ a developer we introduced to you — directly or through another intermediary — without first agreeing terms with us. The restriction is mutual: we will not approach your staff either.

The point of it is narrow. It stops the specific scenario where an introduction is used to bypass the business that made it, which would make vetting and shortlisting free work that nobody could afford to keep doing. It is not a claim over the developer’s career.

What Happens If You Want to Hire Them

You tell us, and we negotiate. That is genuinely the whole process. A permanent hire is a normal outcome of a good engagement, not a betrayal of one, and we would far rather agree a fee and keep working with you than block a move and lose both the client and the developer.

The usual shape is a buyout reflecting the cost of finding, assessing and engaging that person, commonly reduced according to how long the engagement has already run — the longer they have worked with you, the more of that cost has already been recovered through the rate. It is a number to discuss, not a fixed penalty.

Talk to the Developer First

You are allowed to. The awkwardness people imagine comes from doing it secretly. Ask them whether they would want a permanent role, then tell us — in that order if you prefer. Nobody here will pressure a developer into declining an offer they want.

If They Approached You

Say so. If a developer contacted you independently, or you already knew them through a route that had nothing to do with us, that is a different situation and we will look at the facts rather than assume the worst. Silence is what turns a fair conversation into a dispute.

What We Will Not Do

We will not tell a developer they are contractually prevented from taking a job they want, and we will not use the clause to extract a fee disproportionate to the work it represents. A restriction that punishes people for succeeding does not survive contact with a reference check.

Verification and Access

Who They Are, and What They Can Reach

Identity and access are the two practical risks in this model. Both are handled before anyone opens a pull request.

Identity and Background

Developers are identity-verified and their work history is checked before they are engaged — the person in the interview is the person who does the work, and the person on the profile is the person in the interview. There is no bench-swapping after you have chosen somebody.

If your own compliance programme requires specific checks — a particular form of background screening, a signed declaration, evidence of right to work in a given arrangement — raise it during contracting. Some checks are straightforward, some vary by country, and it is far better to establish what is possible before a candidate is shortlisted than after you have decided you want them.

Access to Your Systems

Developers work in your accounts, your repository and your infrastructure, under credentials you create and control. That keeps the audit trail in one place and means access ends the instant you revoke it, without depending on anyone else to act.

Grant the access the role genuinely needs rather than blanket administrator rights. Production credentials in particular should follow whatever rule you apply to your own staff — and if the honest answer is that you do not have such a rule, a new joiner is a good moment to write one. We will work within whatever access model you set, including one where a developer never touches production at all.

Personal Data and Your Users

Where a developer will handle personal data belonging to your customers, you remain the party deciding why and how it is processed, and the obligations belong in the engagement rather than in an assumption. Tell us during contracting which regime applies to you and what it requires, including any data processing agreement you need signed, and we will work within it. If your rules mean a developer should work against anonymised or synthetic data rather than a production copy, say so early — it is a normal constraint and it shapes how onboarding is set up.

What this website collects from you, separately from any engagement, is described in the privacy policy, which also explains how candidate and developer data is kept apart from client enquiries.

Exit

What Happens to Access and Knowledge When It Ends

Engagements end, and most of them end for ordinary reasons. The exit is worth planning before it happens, because the day someone leaves is the worst day to work out what only they knew.

You Revoke, We Confirm

Because the developer works under accounts you created, you end their access yourself rather than asking us to arrange it — repository, ticket tracker, chat, CI, cloud console, anything they were granted. Do it on the last day rather than when you next think of it. We confirm from our side that the engagement has ended and that they understand their obligations continue.

Credentials Get Rotated, Not Just Revoked

Anything the developer could have seen should be rotated as well as revoked: shared API keys, service account tokens, database credentials, anything that was pasted into a chat during an incident at two in the morning. Revoking a user account does not invalidate a secret they once read. This is standard practice for any departing engineer and is no reflection on the individual.

A Written Handover

Work in progress, unmerged branches, the reasoning behind a decision that is not obvious from the code, the thing that breaks if you deploy on a Friday. We ask for that in writing rather than in a leaving call, because a document survives and a conversation does not. If notice is being served, the handover is written during it rather than on the last afternoon.

Copies on Our Side Deleted

Anything of yours held on our side in connection with the engagement — documents, exports, credentials that were shared with us rather than with the developer directly — is deleted. Confidentiality and the intellectual property assignment do not expire with the engagement; they continue afterwards, which is exactly what you want given that the code is still running.

Get the NDA in Place, Then Tell Us Everything

Ask for a mutual NDA in your first message and the detailed conversation can start covered. After that: the role, the seniority and the hours, and profiles follow within three business days.

Request Developer Profiles Call +91 63530 74980

You Are About to Give a Stranger Access to Your Codebase