Terms of Service

1. What we provide

JS Devs supplies software developers who work as part of a client’s team. We are a staffing business: we identify, assess and engage developers, and we make them available to you on an agreed basis. We do not take delivery responsibility for your product, your roadmap or your release schedule, because you direct the work. The one exception is fixed-scope work — a code audit, a migration, a defined build — which is quoted and delivered as a piece of work in its own right and is governed by the statement of work agreed for it.

2. The staffing relationship

Developers are engaged through JS Devs. They are our contractors or personnel, not your employees, and no employment relationship arises between you and the developer by virtue of an engagement under these terms. Payroll, taxes, statutory contributions and employment obligations in the developer’s own country are our responsibility, not yours.

Within the engagement you direct the work: you set priorities, review the output and decide what gets built. That is the point of the model. It does not convert the developer into your employee, and neither party should represent the arrangement as employment to a third party. If your own jurisdiction has rules about how long-term contractor arrangements must be structured, tell us during contracting rather than after, and we will work within them.

3. Engagement types

Engagements run part-time, full-time, or project-based. A full-time developer is dedicated to you for the contracted hours and is not shared with another client during them. A part-time developer works the agreed hours and may have other commitments outside them, which is disclosed before the engagement starts. Project-based work is scoped, quoted and delivered against a statement of work. The type, the hours and any required time-zone overlap are fixed in writing before anyone starts.

4. Rates, invoicing and payment

Rates are quoted in United States dollars, per developer, either per month or per hour depending on the engagement. Rates reflect seniority, the specific technology stack and the engagement type, and the applicable rate is stated in the agreement before work begins. Rates are not quoted as a project cost, because what you are engaging is capacity rather than a deliverable.

Invoices are issued on the agreed cycle — normally monthly in arrears for ongoing engagements — and payment terms are set out in the agreement. Hourly engagements are invoiced against recorded hours with the breakdown supplied alongside the invoice. Bank charges, currency conversion costs and any taxes properly payable in your own jurisdiction are yours; taxes payable in ours are ours. Persistent non-payment entitles us to suspend the developer’s work on notice, and we would always rather raise a payment problem early than stop work without warning.

5. What the rate does not include

The rate covers the developer’s contracted time, their own working equipment and our administration of the engagement. It does not cover your infrastructure and hosting, third-party software licences or SaaS seats, anything a developer is asked to purchase on your behalf, or travel and accommodation if you ever require someone on site. There is no separate recruitment fee, onboarding fee or placement fee layered on top of the rate.

6. Minimum engagement and notice

Any minimum engagement period is stated in the agreement. Notice to end an engagement, and the length of that notice, is likewise stated in the agreement and applies to both sides equally. Notice exists because a developer has planned their availability around your work; it is not a mechanism for retaining an unhappy client. Notice must be given expressly and in writing — an engagement is not ended by work quietly ceasing to arrive, and hours remain payable through the notice period whether or not you choose to use them.

7. The replacement guarantee

If a developer is not the right fit, we will replace them at no cost to you, subject to the following conditions:

• You raise the issue within two weeks of that developer starting on your engagement. Billing for that developer stops from the point you raise it.
• You tell us what specifically was wrong. A replacement chosen without that information is a different person rather than a better one.
• The replacement goes through the normal shortlist and interview process, so you choose the replacement rather than receiving a substitution.
• The guarantee covers fit and capability. It does not cover a change on your side — a cancelled role, a shelved project, a withdrawn budget, or a requirement that changed materially after the developer started. Those are handled under the notice terms in clause 6.
• It applies once per role. A second replacement in the same role is a conversation about whether the brief describes something we can actually fill, and we would rather have that conversation than keep swapping people.

The guarantee is limited to replacing the developer. It is not a refund mechanism for work already performed, and it does not extend to consequential costs arising from the mismatch.

8. Non-solicitation and direct hire

This is the clause that matters most in staffing, so it is stated plainly rather than buried.

During an engagement and for an agreed period after it ends, you agree not to engage, employ or contract directly with a developer introduced to you by JS Devs, or to arrange for that developer to work for you through another intermediary, without first agreeing terms with us. The same restriction runs the other way: we will not approach your staff.

This is not intended to trap anyone. If you want to hire a developer permanently, say so — it is a normal outcome and a negotiable one. A direct hire is settled by agreement, typically as a buyout fee reflecting the cost of finding, assessing and engaging that person, and often reduced according to how long the engagement has already run. We will not stand between a developer and a good offer out of spite, and a developer who wants to take a permanent role will not be obstructed. What the clause prevents is the arrangement being made around us without a conversation, which is the version that damages trust on all sides.

If a developer approaches you independently, or you meet them through a route that has nothing to do with us, tell us. We will look at the facts rather than assume the worst.

9. Confidentiality

Each side will keep the other’s confidential information confidential, use it only for the engagement, and disclose it only to people who need it for the engagement and are under equivalent obligations. This covers your codebase, your credentials, your commercial information, your customers’ data and your plans; it also covers our rates, our assessment material and the personal information of developers we introduce.

We will sign your NDA, or provide a mutual one, and we would rather that document is in place before you describe your systems in detail. Developers placed on your engagement are bound by confidentiality obligations as well, so the duty reaches the person actually reading your code. Confidentiality obligations survive the end of the engagement.

10. Intellectual property

Intellectual property rights in work produced for you during an engagement vest in you. The assignment runs through both our agreement with you and our agreements with developers, so there is no gap in which a contractor retains rights they could later assert. This covers source code, configuration, documentation, designs and other material created as part of the work.

Three ordinary exceptions apply. Open-source components keep their own licences and are not ours to assign. Third-party services and libraries remain governed by their own terms. General skill, technique and know-how that a developer possessed before the engagement, or acquired in the ordinary course of being a developer, remain theirs and can be used elsewhere — what does not travel is your code, your data and anything specific to your business.

11. Data protection and access

Where a developer handles personal data belonging to your users, you are the party that decides why and how it is processed, and the obligations should be written into the engagement rather than assumed. Tell us during contracting which regime applies to you and what it requires, and we will work within it, including signing a data processing agreement where one is needed.

Access to your systems is granted by you, scoped by you and revocable by you. We ask that access follows the same rules you apply to your own staff, and that production credentials in particular are granted deliberately rather than by default. What this website itself collects is covered in the privacy policy.

12. What we cannot guarantee

We guarantee the process, not the outcome. Specifically: we do not guarantee that a developer will be available for any particular role at any particular time, that a shortlist will contain someone you want to hire, that a feature will be delivered by a date you have chosen, that a system will reach a performance target, or that a commercial result will follow from the work. Those depend on your requirements, your architecture, your decisions and factors outside anyone’s control. We will tell you when we think a target is unrealistic, and we would rather say so before you commit than afterwards.

13. Limitation of liability

Neither party is liable to the other for indirect or consequential loss, loss of profit, loss of revenue, loss of anticipated savings, loss of business opportunity or loss of data, however arising. Our total aggregate liability in connection with an engagement is limited to the fees paid by you to us under that engagement in the period specified in the agreement. Nothing here limits liability that cannot lawfully be limited, including liability for fraud or for death or personal injury caused by negligence.

14. Termination

Either party may end an engagement on the notice in the agreement. Either party may end it immediately for material breach that is not remedied within a reasonable period after being notified in writing, or on insolvency of the other party. On termination: fees for work performed up to the end date remain payable, you revoke the developer’s access to your systems, the developer hands over work in progress and anything undocumented, and confidentiality and intellectual property provisions continue to apply. We ask that handover be written down rather than delivered verbally, because a document survives and a conversation does not.

15. Use of this website

The content on jsdevs.in is provided for information. It is not an offer capable of acceptance, and nothing on the site forms a contract until an agreement is signed. Do not submit credentials, API keys or sensitive material through the forms on this site. We may change the content of the site at any time.

16. General

The signed agreement for an engagement, together with any statement of work, takes precedence over this page where they differ. Neither party may assign an agreement without the other’s written consent, except to a successor of substantially the whole business. If any provision is held unenforceable, the rest continues in force. A failure to enforce a term is not a waiver of it. Neither party is liable for failure to perform caused by events genuinely outside its reasonable control.

17. Governing law

The governing law and the forum for disputes are set out in the signed agreement, and they are agreed rather than imposed — clients are international, and a term that makes sense for one jurisdiction may not for another. In the absence of an express choice, the law of the place in which JS Devs operates applies. Both sides agree to raise a dispute directly and attempt to resolve it in good faith before starting proceedings, because almost every commercial disagreement we have seen was cheaper to fix with a conversation.

Contact

Questions about any of this before you sign something: info@jsdevs.in, or call +91 63530 74980 Monday to Friday, 10:00–19:00 IST. The contracts and IP page covers ownership, NDAs and the direct-hire position in more practical detail.