Tuesday, 9:40. The tech lead of the billing team at an e-commerce company in Amsterdam receives a resignation from her best backend engineer. Two weeks’ notice. A new payments module he has been leading goes live in a month. HR says hiring a senior Java engineer permanently will take two to three months, and whoever they find will probably have a notice period of their own before they can start. The tech lead needs someone at the keyboard next Tuesday who can absorb the knowledge before the leaver walks out.
Five working days is very little. Too little for recruitment, enough to fill a role through a vendor, but only when both sides know what they are doing. Most attempts end two weeks later with one of three outcomes: the vendor sent fifteen CVs and none of the people is available; the right candidate is ready but waits a week for a laptop and VPN; or someone starts on time and after three days it is clear they cannot handle the work.
This article is written for the tech lead who has to fill a role fast and well. We show when five working days is a realistic goal and when it is an empty promise, what the plan looks like day by day, what to demand from the shortlist and the technical check, which access to prepare, and which contract terms protect you when you are in a hurry.
Is filling a developer role in five working days actually realistic?
It is, but not through permanent hiring. Candidates in permanent jobs almost always have a notice period, set by contract or by law. In Poland, where many nearshore engineers are based, Article 36 § 1 of the Labour Code sets statutory notice for an indefinite employment contract at two weeks with less than six months’ tenure, one month with at least six months and three months with at least three years. The experienced senior you want usually falls in the last group. Even if you found them in a day, they would start in a quarter.
A developer “available now” is therefore, in practice, a specialist who is free today: finishing a project with a vendor, between assignments, or waiting in a vendor’s pool. Five working days is realistic only when such a person exists and fits your role, and you are ready to decide quickly.
Three conditions must hold at once. First, the vendor has available, previously vetted specialists in your stack and is not starting a search from scratch. Second, your role is described precisely enough that the vendor does not have to guess whom you want. Third, there are no bottlenecks on your side: someone has time to interview on the day candidates are ready, the contract does not need three weeks in legal, and access can be granted in a day.
If any condition is missing, ten working days is the realistic target. That is still several times faster than recruitment, and it is better to plan ten days honestly than to promise the team five and explain the delay.
The role itself also decides what is realistic. Senior Java, Python, React or .NET are skills where vendors with large networks usually have someone finishing a project or available now. Roles that need a rare combination, such as experience with a specific core banking system, a narrow SAP module or a security clearance, are rarely available off the shelf. For those, it is more honest to plan two weeks from the start and ask for accuracy rather than speed.
Finally, put a price on each day of delay, because that tells you how much speed is worth. If a revenue-relevant release slips by a week, the cost is usually many times the rate difference between a senior available now and an ideal candidate in a month. If nothing urgent is waiting, spend an extra week on a better match.
What must be ready on your side before you call a vendor?
The most common cause of delay in an urgent placement is not the vendor but the client. Before you send the request, prepare six things. Each takes an hour; missing any of them can cost days.
A one-page role profile. The stack, separating required from nice-to-have skills, experience level, the scope of the first tasks, how the team works, time zone and working pattern (remote, hybrid, on-site). The more specific the profile, the fewer candidates fall at interview. Templates for the most common roles are in our “How to hire” series: Java, Python, React and DevOps.
A decision-maker and their calendar. Who runs the technical interview and who decides. Block two interview slots on day three before you have even seen a candidate. If only one person can interview and their week is full of meetings, five days is not realistic.
A framework contract or at least an approved template. If this is your first engagement with a vendor, the contract’s journey through legal and procurement is usually the longest part of the whole process. The fix is a framework agreement signed in advance, under which an urgent placement is just an order, or a template agreed beforehand with the vendors you want to use.
NDA and security requirements. Must the specialist sign your NDA, complete security training, pass a background check? Requirements the vendor learns about on day three add days.
An approved rate band. Urgent placements often stall on who approves the rate. Agree beforehand the band in which you can decide alone. A reference point is our pricing page: a senior backend developer costs €335–485 per day and a tech lead or architect €485–650, fully loaded. With approval for the band, you do not lose a day to a budget request once the candidate is chosen.
An access and equipment list. What the specialist will need on day one and who grants it. We return to this below, because it is the most common reason the first week is lost.
What does the five-working-day plan look like?
The plan assumes the vendor has available specialists and you have prepared the items above. Each day ends with a concrete artefact; no artefact at the end of a day is a sign the deadline is at risk.
Day 1: brief and confirmation. In the morning you send the role profile and call the vendor to walk through it in thirty minutes. The vendor confirms whether it has available people and gives an indicative rate range. By the end of the day you have confirmation that the shortlist will be ready tomorrow, or a clear statement that nobody is available now. The second answer is valuable: you know on day one to look elsewhere.
Day 2: shortlist. The vendor sends two or three profiles with confirmed availability, a rate and a note from its own vetting. You review them with the interviewer and pick tomorrow’s candidates. By the end of the day interviews are booked.
Day 3: technical check. Interviews of 60–90 minutes each. After each one, record a decision immediately, not “at the end of the week”. By the end of the day you have chosen and told the vendor.
Day 4: contract and access. An order under the framework agreement or a signed contract, NDA, access requests submitted, equipment prepared or instructions for the specialist’s own device. By the end of the day the specialist has credentials, or at least confirmation they will be ready in the morning.
Day 5: first working day. A welcome session with the lead, environment set up, an architecture walkthrough, a buddy and a first small task assigned. By the end of the day the specialist has a working environment and knows what they are doing tomorrow.
In this plan day five is not a day of full productivity but the first day of work. If you need someone who can take over knowledge from a departing predecessor on day five, the plan is enough. If you need someone who ships a feature to production on day five, no plan will deliver that.
Mind the calendar. If you send the request on a Thursday, day five falls on Wednesday, and a weekend in the middle invites lost momentum: candidates reply on Monday, IT grants access on Tuesday. Where you can, start on a Monday or Tuesday. Watch out for holiday periods, when the vendor and your own legal or IT teams run on reduced staff, and remember that a vendor in Poland and a client in the Netherlands do not share every public holiday.
What does the day-by-day plan look like in one table?
The table puts the plan in a form you can send to the vendor with your request and pin above the coordinator’s desk. The last column shows the most common cause of delay on each day; look there first when the deadline starts to slip.
| Day | What the vendor does | What you do | Artefact at end of day | Most common cause of delay |
|---|---|---|---|---|
| 1 | Discusses the profile, checks pool availability | Send the profile, confirm the decision-maker | Availability confirmed, or a quick “we have nobody” | Vague profile, no decision on whom you want |
| 2 | Sends 2–3 profiles with availability, rate and vetting note | Review with the interviewer, book interviews | Technical interviews booked | CVs without confirmed availability |
| 3 | Organises interviews, answers questions | Run 60–90 min interviews, decide the same day | Candidate chosen | Interviewer has no time, decision postponed |
| 4 | Prepares the order or contract, collects NDA | Approve the contract, request access and equipment | Signed documents, access requests in progress | Contract stuck in legal, no framework agreement |
| 5 | Account manager checks in with specialist and you | Run day one, assign a buddy and a task | Working environment, first task | No access, laptop in transit, nobody has time |
Notice that on three of the five days the most common cause of delay sits with the client. That is not a criticism but a hint: if you want five days, start by removing bottlenecks in your own organisation before you demand speed from a vendor.
What should you demand from the shortlist?
The shortlist is where a vendor shows whether it understands urgency. A good one saves you a day; a bad one costs two. Demand five things.
Two or three candidates, not fifteen. A long list of CVs means the vendor has pushed selection onto you. On a five-day timeline you have no time to read fifteen profiles and interview six people.
Confirmed availability with a date. Each candidate should have a confirmed start date and confirmation that they know about your role and are interested. A candidate who does not know they are being presented is a frequent and costly problem.
A rate for each candidate. Discovering after the technical interview that the chosen candidate is outside the budget costs a day.
Notes from the vendor’s own vetting. Who spoke to the candidate, what was checked, strengths and gaps against your profile. That lets you focus your interview on what the vendor did not check.
Honesty about gaps. A good vendor writes plainly: “strong Spring Boot experience, has not worked with Kafka”. A profile that matches every line of your request often means the CV was tailored to the request, not that the candidate is perfect.
If a vendor cannot deliver a shortlist meeting these requirements on day two, it probably has nobody available and is only starting to search. Better to know on day two than on day five.
How do you run a technical check in a single day?
An urgent placement has no room for a multi-stage process with a take-home task. One well-prepared technical interview of 60–90 minutes gives enough information, provided the vendor has done its own vetting and you know what you are looking for.
First 15 minutes: the last project. Ask the candidate to describe the last system they worked on: architecture, their role, the hardest problem. Probe for detail. Someone who really built a thing can go three levels deeper; someone who was only nearby stops at the first.
Next 30–40 minutes: code review. Show a snippet similar to your code with a few planted problems: poor exception handling, an N+1 query, missing validation. Ask for a review out loud. This is closer to daily work than whiteboard algorithms and shows how the candidate reads someone else’s code, which is exactly what they will do in their first weeks.
For seniors, 15–20 minutes: an architecture decision. Describe a real problem from your system and ask how they would solve it and what trade-offs they see. You are not looking for the “right” answer but for how they think.
Last 10 minutes: the candidate’s questions. The questions a candidate asks say a lot about their experience and engagement. No questions at all is a warning sign.
Prepare a simple scorecard before the interview: four or five criteria from the role profile, each scored one to three, plus one sentence of justification. If two people interview, each fills in the card separately before comparing. The point is that every candidate is judged on the same criteria, not that the one interviewed last is remembered best.
Decide the same day. Postponing “to think about it” on a five-day timeline loses a day, and sometimes the candidate, who meanwhile receives another offer. If you have doubts that another conversation will not resolve, it is better to say no and ask for the next candidate than to accept someone and hope it works out.
How can you tell whether the vendor really vetted the candidate?
Speed tempts vendors to cut their own vetting and rely on the client to catch problems at interview. In a five-day process your interview is short, so the vendor’s vetting has to be solid. Ask four questions.
What does your vetting process look like, and how many stages does it have? A good vendor has a documented process that includes at least one technical interview with an engineer, not only with a recruiter, and can describe it without opening a slide deck.
Who spoke to this candidate, and when? A note from a year ago for another role is not vetting for yours. Ask for the date and whether the conversation covered your stack.
Has the candidate worked for other clients through you, and how did it go? A specialist with successful engagements through the same vendor is a lower risk than someone sourced yesterday.
What happens if the candidate does not work out in the first weeks? This is the question about the replacement guarantee, which matters even more for a fast placement. How to write it into the contract is covered in our article on the replacement guarantee and SLA in staff augmentation.
A warning sign is a CV that looks rewritten for your request: the same phrases as your profile, technologies in the same order. It does not always mean dishonesty, but it is always worth asking the candidate directly about each key technology.
If you have an extra half hour, ask the vendor for a contact who worked with the candidate on a previous engagement through the same vendor, or a short note from that engagement’s account manager. Such a reference does not replace the technical interview, but it quickly shows how the candidate behaves in a team, whether they meet deadlines and how they react to code review comments.
Which access should you prepare so day one is not wasted?
The most common failure in an urgent placement looks like this: the specialist starts on time and spends the first three days waiting for a repository account, VPN access and IT’s answer about a laptop. Formally the role was filled in five days; in reality work starts on day ten.
Prepare the access list before you have chosen the candidate and trigger it the day the order is signed. For a backend developer it usually includes:
- an identity and email account, if the specialist is to work in your domain,
- VPN or other remote access,
- code repositories, with permissions limited to what the role needs,
- the issue tracker, documentation and the team’s chat,
- development and test environments and test data,
- the CI pipeline and code quality tools.
Apply two security rules from day one, even in a hurry. The first is least privilege: the specialist gets access to what the role needs, not a copy of the departing senior’s permissions accumulated over years. The second is no production access at the start unless the role genuinely requires it; production access can follow after a few weeks.
Settle the equipment question too. Will the specialist work on your laptop or on their own, under your security policy? Shipping and configuring a company laptop across a border can take a week. If your policy allows work on the vendor’s or the specialist’s equipment, agree the requirements, such as disk encryption, device management and patching, in advance. If the specialist is in another country, also check whether your data protection rules allow the data they will touch to be accessed from there, and record that in the order.
How should you plan the first two weeks so the specialist delivers quickly?
Filling the role in five days achieves nothing if the specialist then spends three weeks reading code alone. The plan for the first two weeks should be ready on day one.
A buddy. One team member is responsible for answering the newcomer’s questions for two weeks and has time reserved for it. When taking over from a leaver, the best buddy is the leaver, for the days they have left.
A first task on day one. Small but real: a bug fix, a small test, a minor change in the module the specialist will own. A task that goes all the way from ticket through code review to release teaches more than a day of reading documentation.
Knowledge transfer from the predecessor. A list of topics, sessions at the code, recordings. With a two-week notice period and a five-day placement you have about a week of overlap. Plan it hour by hour.
A review after the first week. A short conversation between the lead and the specialist, and feedback to the vendor. If something is wrong, you know inside the replacement guarantee period, not after it.
For that review, prepare three concrete questions instead of “how’s it going”. Does the specialist have a working environment and access to everything they need? Did the first task pass code review, and what were the comments? Do they know whom to ask about what, and do they get answers in reasonable time? The answers say as much about your onboarding process as about the specialist, and both are useful.
A full remote onboarding scenario with a daily agenda is in our remote IT specialist onboarding playbook.
Which contract terms protect you when you are in a hurry?
Haste is the best moment for a vendor to slip in unfavourable terms and the worst moment for a client to read them. So set the terms for urgent placements in a framework agreement before the urgent need arises. Five clauses matter most.
A replacement guarantee with a short initial period. With a fast placement the risk of a poor fit is higher, so free replacement in the first weeks is essential. The date of notice, not the date of replacement, should decide whether the guarantee period was met.
A replacement deadline for departures. The number of business days from notice to the successor’s first day.
No rush premium hidden in the rate. Check whether the vendor adds charges for express placement. If it does, judge whether they are justified and fix them in the framework agreement, not in an order negotiated under pressure.
Short notice. If the urgent placement is a bridge until you hire permanently, you need to be able to end the engagement with a few weeks’ notice.
A conversion option. If the person placed in a hurry might stay longer, or even move to your payroll, agree conversion terms upfront.
The framework agreement is the key tool here, because it moves negotiation from a moment of haste to a moment of calm. It contains all general terms: rates or how they are set, the replacement guarantee, notice, confidentiality, IP. An urgent placement then becomes a short order with a name, role, rate and start date that can be signed in a day. If your company uses external specialists regularly, signing framework agreements with two or three proven vendors is the cheapest way to cut a week from every future urgent placement.
Which warning signs show that “available now” means “anyone”?
A vendor promising a developer available now in any technology, at any level, every time, is promising something nobody can deliver. Seven signs should turn on a red light.
No questions about the role. The vendor does not ask about the team, the tasks or the way of working, it just sends CVs. That means it is matching keywords, not people.
A shortlist without confirmed availability. Candidates “can start soon” or “after a conversation with their current client”.
No vetting notes. The vendor cannot say who spoke to the candidate, or when.
Pressure to decide without an interview. An offer to “start tomorrow and talk along the way”. For a senior role that is asking for trouble.
No replacement guarantee, or only a verbal one. “Of course, if something doesn’t work we’ll figure it out” is not a guarantee.
A senior rate far below the market. It may mean the senior is really mid-level, or that the vendor makes its money somewhere else.
No account manager. After signing, nobody on the vendor’s side asks after a week how it is going and reacts before a small fit problem turns into a replacement. In a fast placement, where the risk of a mistake is higher, that role matters more.
None of these signs rules out a vendor automatically, but two or three together should send you looking for an alternative, even at the cost of extra days.
How does ARDURA Consulting fill urgent roles?
Our timelines are published, so you can compare them with what you need. As standard we deliver vetted specialists within 2 weeks: days 1–3 for requirements and shortlisting from more than 500 experts, days 4–7 for technical interviews and skill verification, days 8–14 for contract and onboarding. Urgent placements are handled in 48–72 hours from our pre-vetted pool. Our page on IT staff augmentation in Poland describes this as a 2-week onboarding SLA: from signed contract to engineer productive in your repository within 14 days.
Our available experts page shows profiles of specialists ready to start within one to two weeks, some marked as available as soon as possible. Each expert is thoroughly vetted.
Every specialist passes our 5-stage vetting process, and you interview and approve every candidate before the engagement starts. If a specialist isn’t the right fit in the first 2 weeks, we replace them at no cost, and if a specialist leaves during the engagement, we guarantee a replacement within 5 business days. Monthly contracts are available with no long-term commitment, rates are fully loaded with no recruitment fees, and dedicated account managers monitor performance continuously, so the first-week review described above has a named counterpart on our side.
To be straightforward: five working days from request to first day of work depends on whether our pool holds an available person who fits your profile, and on how quickly the interview, contract and access move on your side. Ask about that directly in the first conversation, with us or any other vendor, before you promise the team a date.
How do you prepare the team for the next urgent need?
Back to the tech lead in Amsterdam. In the best case her company already has a framework agreement with a vendor, the senior Java role profile sits in the documentation repository, and the access list for a new developer is a template in the ticketing system. Then Tuesday’s resignation triggers a procedure, not panic: Wednesday morning brief, Thursday shortlist, Friday interviews, Monday contract and access, Tuesday first day of work and a week of handover from the leaver.
If none of that exists, five working days is unlikely, but ten is still within reach. What matters most is not to return to the old state after the first urgent placement, but to keep the pieces ready for next time.
Remember five things. First, a developer available now is a specialist who is free today, not a recruitment candidate, because notice periods rule out a five-day start for permanent hires. Second, five working days requires readiness on both sides: available, vetted specialists at the vendor; a profile, a decision-maker, a contract and access on yours. Third, demand a shortlist of two or three candidates with confirmed availability, a rate and a vetting note. Fourth, one 60–90 minute interview with a code review is enough if the vendor has done its part, and decide the same day. Fifth, prepare access and the first two weeks before day one, and schedule a review inside the replacement guarantee period.
If you need someone now, check our available experts, see how our staff augmentation services work, or send us the role profile and we will check whether our pool holds an available person who fits it.