From a Short Brief to Somebody in Your Standup
No requirements document, no discovery phase, no proposal deck. You describe the role, we send two or three vetted profiles within three business days, and you run your own interview from there.
- Profiles in 3 business days
- You interview and you decide
- Two-week replacement guarantee
Six Steps, and What Each One Costs You in Time
Most of the elapsed time between a first email and a developer writing code is your interview scheduling and their notice period. Very little of it is us.
1. Share the role — about fifteen minutes of your time
Send the stack, the seniority, the hours a week and a couple of sentences about the work itself. “React and Node, mid to senior, full-time, mostly building out our reporting module and fixing the dashboard performance complaints” is a complete brief and tells us more than three pages of competency framework would.
What is not needed: a formal job description, a years-of-experience threshold, a list of every library in the repository, a scoring matrix, or a salary band. We will ask about budget, but as a conversation rather than a form field. If you are still deciding between part-time and full-time, say that too — it changes who we approach.
2. Two or three vetted profiles within three business days
You get a small shortlist rather than a long one. Each profile covers what the developer has actually built, which parts of your stack they have used in production rather than in a tutorial, their availability, their working hours and their notice period. If we think one of the three is a stretch on some dimension, that is written in the profile rather than left for you to discover in the interview.
If the brief is unusual enough that three days is optimistic, we tell you on day one. A slipped date you were warned about is a scheduling problem; a slipped date you found out about on day four is a trust problem.
3. Interview with your own process
You run whatever you normally run. A pairing session in your codebase, a take-home, an architecture conversation, a culture chat with the team they would join. We do not sit in unless you want us to, and we do not coach candidates on your questions. Scheduling usually takes longer than the interviews themselves, so book the slots before you read the profiles if you are in a hurry.
Rejecting all three is a normal outcome, not an awkward one. Tell us what was wrong and the next set is better targeted. That feedback loop is most of the value in a small shortlist.
4. Decide, then we handle the paperwork
Once you pick somebody, we confirm the rate, the hours and the start date, and issue the contract. That covers confidentiality, assignment of intellectual property in the work to you, and the notice terms on both sides. Details are on contracts and IP. You sign one agreement with us rather than an employment contract with an individual in another country.
Start dates are usually one to three weeks out. Somebody already between engagements can start almost immediately; somebody currently placed needs to serve notice, and we will not ask them to break it.
5. Onboarding in the first week
The developer joins your standup, your board, your repository and your chat on day one, not week two. We ask you to give them a named person to ask questions of and one small, real task to finish early, because a merged pull request in the first few days does more for confidence on both sides than a week of reading code.
Expect the first week to be slower than a permanent hire, and expect week three to look normal. Anyone who tells you a contractor is at full speed on Monday morning has either not done it or is not watching closely.
6. The two-week replacement window
For the first two weeks, if the developer is not right, we replace them at no cost. The window is deliberately short and early because that is when a mismatch is actually visible — on day four somebody is clearly struggling with the codebase, and by month three the question is performance management rather than fit.
Using it is not a failure of the process, it is the process. Tell us the specific reason and the replacement is aimed properly; tell us only that it did not work and you get someone different rather than someone better.
What We Need From You for This to Work
Short list, and none of it is unusual. The engagements that go badly almost always miss one of these rather than failing on skill.
Someone who can answer questions
Not a full-time mentor — a named person who responds within a few hours during your overlap window. A new developer has perhaps thirty small questions in the first fortnight, and every unanswered one becomes a guess that somebody reviews later.
Access on day one
Repository, ticket board, chat, staging environment and whatever credentials the work needs. Access requests that take a week are the single most common reason a first sprint disappoints, and you are paying for that week either way.
A backlog with enough in it
Two or three weeks of visible work, prioritised. A developer who runs out of tickets on Thursday will either ask you repeatedly or invent work, and neither is what you hired them for.
Code review that actually happens
Pull requests that sit for four days teach a new developer that nothing is urgent and nothing is checked. Review in a day, even briefly, and the standard of what arrives next rises without anyone having a conversation about it.
An agreed overlap window
Pick the hours you need live and say so before the engagement starts, not in week two. Overlap is arranged, not assumed, and the realistic options by region are set out on engagement models.
Direct communication, not a relay
Brief the developer yourself. Everything routed through a third party arrives later and thinner, which is why we do not put an account manager in the middle. We are there for contracts, invoicing and anything that is not day-to-day work.
The Most Common Mistake: Writing a Job Spec
A job specification is a document for a hiring committee. It describes a person in the abstract. We need to know what the work is, because that is what we match against.
A specification of a person
- “Five or more years of commercial experience” — a filter that removes strong people and keeps weak ones.
- A list of every dependency in package.json, with no indication which three matter.
- “Excellent communicator, team player, self-starter” — true of every profile ever written.
- Responsibilities phrased so generally that they would fit any product in any industry.
A description of the work
- What is on the board for the next two months, in your own words.
- The two or three parts of the stack this person will live in every day.
- The awkward truth about the codebase: what is old, what is undocumented, what everyone avoids.
- Who they report to, who reviews their code, and how much autonomy they get.
Being honest about the difficult parts of the codebase does not put good developers off. It does the opposite: someone who is told the truth in week zero and finds it accurate in week one starts trusting everything else you say.
Contracts, Invoicing, Notice and Scaling Down
The parts nobody reads until they matter. Here they are in advance instead.
One agreement, with us
You contract with JS Devs rather than with an individual abroad. The agreement covers confidentiality, assignment of intellectual property in everything the developer produces for you, acceptable use of your systems and notice on both sides. We are the counterparty, which means payroll, local tax and employment status are our problem rather than yours.
If your legal team needs a mutual non-disclosure agreement signed before you send us anything about the codebase, ask and we will sign yours rather than insisting on ours.
Invoicing in US dollars
Monthly engagements are invoiced monthly. Hourly engagements are invoiced monthly in arrears against logged hours, and you get the log rather than a single line item. Invoices are in US dollars by bank transfer, and payment terms are agreed before the start date rather than discovered on the first invoice.
There is no setup fee, no recruitment fee on signature and no charge for the shortlist, including when you interview everyone and hire nobody. Rate bands are on pricing.
Notice, in both directions
Two weeks on an hourly part-time engagement, thirty days on a full-time monthly one. The same terms bind us: we will not pull a developer off your team at a week of notice because a better-paying engagement appeared, and if a developer resigns from us we carry the handover rather than presenting it to you as your problem.
Notice is about handover. What you are protecting is the half-finished branch and the context that only exists in one person, not a penalty clause.
Scaling down without ending
You can drop from full-time to part-time at the same notice as ending, which is often the better move when a release lands and the next phase is not funded yet. Keeping a developer at two days a week preserves the knowledge you have already paid to build, and restarting later is far cheaper than hiring from scratch.
Scaling up is quicker than scaling in: adding a second developer to an engagement that is already running rarely needs a new agreement, just a start date. See dedicated teams if the answer keeps being “one more person”.
What Actually Delays a Start Date
None of these are about finding the developer. All of them are avoidable if you know about them in week zero.
Questions About the Hiring Process
What do you actually need from me to start?
Four things, and they fit in a short email or a fifteen minute call: the stack, the seniority, how many hours a week you need covered, and roughly what the person will be working on. A link to a job description is fine as background, but it is rarely the useful part. Two or three honest sentences about the work waiting for them helps far more.
Why three business days rather than the same afternoon?
Because a same-day shortlist means sending whoever is free rather than whoever fits. Three days is roughly what it takes to read the brief properly, approach people who match it, confirm they are genuinely available and interested, and check that the work you described is work they have actually done. If a stack is rare enough that three days is not realistic, we say so on the first day rather than quietly missing the date.
Can I run my own technical interview?
Yes, and you should. Our vetting exists so that you interview three people instead of thirty, not to replace your judgement about your own team. Run whatever you normally run: a pairing session, a take-home, a system design conversation. If your process has more than two rounds, tell us up front, because candidates need to know that before they agree to it.
What happens in the first week?
Access, a working local environment, a first small task and a named person to ask questions. We tell the developer to expect a slow first week and to ask rather than guess. If you can arrange a walkthrough of the codebase on day one and get a first pull request merged by day three or four, the rest of the engagement usually follows the same rhythm.
How does the two-week replacement window work in practice?
If it is not working inside the first two weeks, tell us and we replace the developer at no cost. In practice a mismatch is visible within the first few days. What turns a replacement into a better fit rather than merely a different one is a specific reason: too junior for this codebase, not clear enough in writing, or much weaker on the backend than the profile suggested.
What notice applies when we want to end an engagement?
Two weeks on an hourly part-time engagement and thirty days on a full-time monthly one, and it runs in both directions. Notice exists for handover rather than as a penalty: it gives the developer time to write down what is half finished and gives your team time to absorb it. If you need to stop sooner we will not make it difficult, but the handover is the thing you lose.
Start the Three-Day Clock
Send the stack, the seniority and the hours. Profiles come back within three business days, and there is no charge for the shortlist.