What a bad engineering hire costs a seed-stage startup

The cost of a bad engineering hire is more than the salary you pay them. The often repeated claim that a bad hire costs 30% of their first year salary is not supported by a clear, current US government source. A better approach is to start with costs that can actually be measured.

Key takeaways

• The US employer cost is higher than salary alone. In March 2026, wages and salaries represented 69.9% of private-industry compensation costs. Benefits represented 30.1%, giving an overall employer cost of roughly 1.43 times gross salary.
• A US software developer is expensive before the mistake is counted. The 2025 BLS mean wage was $148,100. The median was $135,980.
• Employer costs depend on where the developer works. Eurostat reported non-wage labour costs of 32.3% in France and 4.8% in Romania in 2025. The US figure should not be treated as a global rule.
• The seed-to-Series-A window is unforgiving. About 17% of companies that raised seed funding in 2022 reached Series A within two years, according to the cited cohort data. Earlier cohorts had materially higher transition rates.
• Time can be more damaging than the salary itself. A hiring mistake can delay product work, create rework and force another hiring process while the startup is trying to reach its next funding milestone.
• The total cost cannot currently be calculated with precision. There is no reliable current US statistic that captures every part of a bad engineering hire, and developer ramp time is particularly difficult to measure consistently.

The useful question is therefore not simply, "How much does a bad engineer cost?" It is, "How much of the startup's limited runway and progress can one bad hire consume?"

For a US private sector employer, wages made up 69.9% of total compensation costs in March 2026. Benefits accounted for the remaining 30.1%, which puts the employer's total compensation cost at roughly 1.43 times the employee's gross salary.

For software developers, the 2025 US mean wage was $148,100, while the median was $135,980. That means the direct employment cost can already be substantial before you account for the wider cost of a hiring mistake.

The bigger problem at seed stage is time.

A startup has a limited period to turn its funding into enough product progress and traction to raise its next round. For companies that raised seed funding in 2022, only about 17% reached a Series A within two years, compared with roughly 30% to 35% for cohorts from 2017 to 2020.

That makes a bad engineering hire more than a payroll problem. Time spent hiring, onboarding, correcting poor work and eventually replacing someone can consume part of the window in which the company needs to prove that it deserves its next round.

There is also no single global employer-cost multiplier. Labour costs vary significantly by country. Eurostat, for example, reported that non-wage costs represented 32.3% of total labour costs in France in 2025, compared with 4.8% in Romania.

So the real cost of a bad engineering hire needs to be treated as a lower bound rather than a neat percentage. Some components can be measured. Others, such as the time required for a developer to become fully productive, do not have a reliable current peer-reviewed dataset.

In this article:

• What a bad engineering hire actually costs, and where the standard figure comes from
• How to calculate the cost of a bad engineering hire, component by component
• Why the arithmetic is different at seed stage
• How to reduce the risk before you hire
• What a proportionate vetting process looks like at your size
• Conclusion
• FAQ

What does a bad engineering hire cost?

A bad engineering hire costs more than their salary. The problem is that there is no reliable number for the full cost because some of the components have never been properly measured.

What we can calculate is the cash floor. Even that is higher than the figure many founders use.

The number you will often see is that a bad hire costs 30% of their first year's earnings, supposedly according to the US Department of Labor. That claim appears across HR, staffing and recruiting websites. However, a search for the original source on 25 August 2026 found no Department of Labor document supporting the figure. The relevant Department of Labor websites were also inaccessible during the research, so the original attribution could not be verified.

That does not prove the 30% figure is false. It may come from a genuine publication that is no longer publicly accessible. But without the original source, it is not a figure you can confidently use for a hiring decision.

A better approach is to build the cost from figures that can actually be sourced.

According to the BLS Employer Costs for Employee Compensation data for March 2026, private industry employers spent an average of $46.60 per hour on employee compensation. Of that, $32.60 went to wages and salaries and $14.01 went to benefits.

That means wages represented 69.9% of the employer's total compensation cost. Benefits represented the other 30.1%.

Divide $46.60 by $32.60 and you get 1.429.

In practical terms, every $1 of gross salary costs the employer about $1.43 once benefits are included. The multiplier is not a separate government estimate. It is simply the ratio of two published BLS figures.

The next question is how much the engineer earns.

The BLS 2025 occupational employment and wage estimates put the US software developer mean annual wage at $148,100, with a median of $135,980. The mean hourly wage was $71.20, which also lines up with the annual figure when multiplied by a standard 2,080-hour working year.

That gives us a useful starting point. A developer earning the BLS mean salary represents roughly $211,783 in annual employer compensation cost after applying the 1.43 multiplier. The median salary produces an employer cost of about $194,251.

But salary data can look very different depending on the population being measured.

Levels.fyi reports median US software engineer total compensation of $195,000, with $137,000 at the 25th percentile and $391,000 at the 90th percentile. That figure includes total compensation such as equity and comes from a different population than the BLS data.

The two figures should not be averaged. They answer different questions.

BLS data is useful when you want employer-reported wage data across the US labour market. Levels.fyi is more useful when you are looking at software engineers whose compensation includes equity, particularly in higher-paying technology companies.

So the cost of a bad engineering hire should start with the compensation figure that matches the person you are actually hiring. From there, you can add the costs that are harder to measure, such as lost development time, rework and the cost of replacing the employee.

Those costs are where the real problem begins. The salary is measurable. The time your startup loses is much harder to put a precise dollar value on.

How do you calculate the cost of a bad engineering hire?

There are six parts to the cost of a bad engineering hire.

Four can be calculated using public data and your own numbers. Two cannot be reliably measured because there is no published dataset for them. That means any total you calculate is a floor, not a precise estimate.

The six components

The first two components are straightforward once you know the engineer's salary.

For example, if a US engineer earning the BLS mean wage stays for four months, they receive about $49,367 in gross pay. Using the US private industry employer cost multiplier of 1.43, the fully loaded cost is about $70,600.

Your number will depend on the salary and location. The important point is that you can calculate it from published figures rather than applying an arbitrary percentage.

The third component is the time you and your team spend making the original hire and then replacing them. This includes sourcing candidates, reviewing applications and conducting interviews.

That time has a cost even though it does not appear as a separate expense on your bank statement. Add up the hours spent by everyone involved and multiply them by their effective cost to the company. Then do the same calculation for the replacement search.

The remaining three components are harder.

You lose time while the engineer gets up to speed. Your roadmap may be delayed. Work they produce may need to be corrected or rebuilt. These costs can be significant, but there is no reliable published dataset that lets you assign a standard dollar value to them.

The component everyone omits

The employer's non-wage cost is often left out because it varies considerably by location.

In US private industry, benefits accounted for 30.1% of total employer compensation costs in March 2026. For state and local government workers, the figure was 38.5%. Even within the same country, the employer type changes the calculation.

The difference becomes much larger across countries.

Eurostat's 2025 data for the information and communication sector puts the average EU non-wage share at 23.2%. But individual countries vary considerably:

• France: 32.4%
• Spain: 24.1%
• Germany: 20.0%
• Portugal: 19.1%
• Poland: 16.7%
• Romania: 4.2%

France's non-wage share was therefore almost eight times Romania's in the same sector and year.

That is why there is no sensible global employer cost multiplier. The correct approach is to use data from the jurisdiction where the engineer is employed and state exactly what that figure measures.

Gross pay also varies significantly. In 2025, total hourly labour costs in the ICT sector were about €58.50 in Germany, compared with €29.30 in Poland and €26.00 in Romania.

That difference matters when comparing engineering costs across locations. However, it does not tell us anything about engineering quality. There is no public dataset that reliably compares engineering output across these jurisdictions, so the cost data should not be presented as a quality comparison.

Converting the total into months of runway

This is where the calculation becomes more useful for a startup.

Instead of looking only at the dollars lost, calculate how much time the bad hire consumes.

Start with the months the employee spends in the role. Then add the time required to notice the problem, serve any notice period, find a replacement and get the replacement to the point where they are producing useful work.

The result is the amount of runway the hiring mistake has consumed.

Some of these numbers can come from your own records. Others will need to be estimated because there is no current benchmark you can reliably use.

For example, the US does not currently have a replacement for the DHI-DFH Mean Vacancy Duration Measure. That series tracked the average working days required to fill vacancies by industry and firm size, but it was discontinued in February 2018. The FRED record confirms that the series is discontinued.

There is also no peer-reviewed dataset that gives a reliable standard for how long a software engineer takes to become productive. Research on onboarding and developer productivity provides useful frameworks, but it does not give founders a universal ramp-time figure they can simply plug into a cost calculator.

Your own hiring history is therefore more useful.

Look at your last engineering hire. How long did it take to close the position? How long did it take before they shipped useful work independently? How much time did the team spend correcting or reviewing their work?

Those numbers will not be perfect. They are still more defensible than an unsupported industry percentage.

A bad hire at seed stage is not simply a salary loss. It is a loss of runway. And for a startup with limited time to reach its next milestone, that difference matters.

Why is the arithmetic different at seed stage?

Because a seed stage startup is not simply working with an annual hiring budget. It is working against a limited window in which it needs to prove that the business can progress to its next round.

That window has become longer and harder to clear.

Crunchbase News reported in May 2026 that the median US seed round is now about $3 million, roughly three times its 2018 level. At the same time, the median time from seed to Series A has stretched beyond two years. For companies that raised at least $1 million in seed funding, only 24% of the 2023 cohort had progressed further, while the figure for the 2024 cohort was 16%. (Crunchbase News)

Carta's data shows a similar decline. For companies that raised seed funding in 2022, only about 17% reached a Series A within two years. For the 2018 cohort, the figure was roughly 25% to 30%. (Carta)

The two sources use different measurements, so their historical figures should not simply be averaged. Crunchbase reports a broader progression rate, while Carta specifically measures whether a company reaches Series A within 24 months.

For this article, the 24 month figure is more useful because runway is measured in months.

Why months matter more than the salary

Imagine a seed stage startup hires an engineer who turns out to be a poor fit.

They spend four months in the role. The company then spends another month dealing with the departure. Finding a replacement takes two months, and the replacement needs three months to become productive. That is 10 months consumed by one hiring mistake. Against a 24 month window, that represents more than 40% of the period.

The durations in this example are illustrative. They are not industry benchmarks. Your own hiring history should replace them wherever possible.

The important point is the unit of measurement.

At seed stage, the question is not only how many dollars the company lost. It is how many months of its limited opportunity to reach the next milestone disappeared.

How much a hiring mistake costs by stage

The economics change as the company grows.

At pre-seed, there may be very little financial slack. A bad hire can consume founder time and months that the company cannot easily replace.

At seed, runway becomes the critical denominator. A hiring mistake can use a meaningful share of the period available to reach the next funding milestone.

At Series A, the cost shifts toward missed milestones and the credibility of the plan presented to investors.

Later, the direct salary becomes a smaller part of the overall problem. The bigger costs are often team output, management time and disruption.

That is why hiring standards should become more deliberate as the cost of being wrong increases.

For a seed stage startup, a bad engineering hire is expensive because the company is not buying time with its funding. It is spending a finite amount of time trying to reach the next milestone.

The arithmetic is different because the thing you are running out of is not money. It is time.

How do you reduce the risk before you hire?

You cannot remove the risk of a bad engineering hire completely. You can make the decision much easier to test, measure and reverse.

Start before you advertise the role.

1. Define what success looks like

Write down what the engineer must actually produce in their first 90 days.

Focus on the outcome rather than the job description. If you cannot identify something specific that should exist by day 90, the role is probably not defined well enough to hire for.

A detailed vetting process cannot compensate for an unclear target.

2. Calculate the time you can afford to lose

Estimate how long a failed hire would occupy your runway.

Include the employee's tenure, notice period, replacement search and the time needed for their replacement to become productive. Use your own previous hiring data wherever possible.

Then compare that period with your remaining runway.

If a potential hiring mistake could consume more than a quarter of your remaining window, the decision deserves substantially more scrutiny. For some startups, a short term contract engagement may also be worth considering because it can reduce the commitment before making a permanent hire.

3. Structure the interview

Use the same core questions and assessment criteria for every candidate.

Create the scoring rubric before interviews begin. This gives each candidate the same evaluation framework and makes it easier to compare evidence rather than impressions.

It also helps prevent one particularly strong or weak interview from changing the standard halfway through the process.

4. Test the work they will actually do

Give candidates a work sample that resembles the job.

For an engineer, that could involve a small task based on the type of code they would work with after joining. Avoid artificial puzzles when they do not resemble the actual role.

Score the work against criteria you have defined in advance.

The goal is not to see whether someone can complete a clever interview challenge. It is to gather evidence that they can perform the work you are hiring them to do.

5. Get independent assessments

Have more than one person score the candidate independently before discussing the result.

This matters because discussion can influence judgment. If interviewers agree on their impressions before recording their own scores, the final decision may reflect group consensus rather than independent evidence.

Compare the assessments first. Discuss the differences afterwards.

6. Decide in advance when you will review the hire

Set a formal review point before the person starts.

For example, agree on three specific outcomes to assess after 30 days. If those outcomes are not being met, investigate why rather than allowing the decision to drift indefinitely.

This is important because the cost of a bad hire grows with time.

A scheduled review creates a point at which you have to look at the evidence and decide whether the hire is working. It is much cheaper to identify a serious problem early than to discover it several months later.

The evidence behind structured hiring

The third and fourth steps are not simply hiring preferences. They are supported by decades of personnel-selection research.

Structured interviews have generally shown stronger predictive validity than unstructured interviews because candidates are assessed more consistently against defined criteria. Work samples are also useful because they measure performance on tasks that resemble the work itself.

The broader research base has been revised over time, including downward corrections to some earlier estimates of selection-method validity. The important conclusion has remained: structured, job-relevant assessment is more defensible than relying primarily on an informal conversation or gut feeling.

For a seed stage startup, that matters because the goal is not to create a perfect hiring process. It is to collect enough useful evidence before making a decision that could consume months of runway.

The cheapest time to reduce the cost of a bad hire is before you make the hire.

What does a proportionate vetting process look like?

A good vetting process does not need to be long. It needs to be structured and consistent.

Every candidate should be assessed against the same criteria. The tasks should relate to the work they will actually do. The people assessing them should know what good performance looks like before they start.

This matters because hiring research has consistently found that structured assessment is more useful than relying on an informal interview or gut feeling.

What the research actually says

One of the most widely cited reviews of personnel selection research is the work by Schmidt and Hunter, published in Psychological Bulletin. They reported relatively strong validity for combinations involving general mental ability, work sample tests and structured interviews.

Those figures should not be treated as exact predictions of hiring success today.

Sackett, Zhang, Berry and Lievens later revisited the evidence and found that earlier estimates had been affected by statistical corrections that could overstate validity. Their revised estimates were lower, reducing many reported validity coefficients by around 0.10 to 0.20 points. Structured interviews still ranked strongly after the correction.

That distinction is important for anyone designing a hiring process.

The evidence does not say that a particular interview or test can reliably identify the perfect engineer. It says that structured methods provide better evidence than an unstructured conversation.

Earlier research by McDaniel, Whetzel, Schmidt and Maurer reached a similar conclusion. Their analysis covered 245 validity coefficients from 86,311 individuals and found that structured interviews were more valid than unstructured interviews.

So the practical lesson is relatively simple: do not make the process longer just for the sake of making it longer. Make it more consistent. Keep productivity expectations realistic.

There is another reason not to build a hiring process around unrealistic expectations of immediate engineering output.

Research on developer productivity can produce very different results depending on the developers, tools and work being studied.

A 2025 METR randomised controlled trial involved 16 experienced open source developers working on 246 real issues in repositories they already knew. Developers using AI tools took 19% longer to complete the tasks than those working without the tools.

A separate study by Cui, Demirer, Jaffe, Musolff, Peng and Salz combined three field experiments involving 4,867 developers. It found that developers using an AI assistant completed 26.08% more tasks, with larger gains among less experienced developers.

These results appear contradictory, but that is exactly why they are useful.

Developer productivity depends on the people involved, the type of work, the tools being used and the environment in which the work happens. A result from another engineering organisation is not automatically a forecast for your team.

What this means for a startup

Your vetting process should therefore be proportionate to the cost of getting the decision wrong.

If a bad hire could consume a large part of your runway, collect more evidence before making the decision. That does not necessarily mean adding more interviews. Instead, make the existing stages more useful.

Use a consistent interview structure. Give candidates a realistic work sample. Score the evidence against criteria decided in advance. Have interviewers assess candidates independently before discussing their results.

The aim is not to build an enormous hiring machine. It is to make the decision harder to get wrong and easier to explain.

Where this leaves the decision

The reason to pay for deeper assessment is not that it eliminates hiring risk. It is that it can reduce the amount of risk your startup carries itself.

RocketDevs assesses developers for 6-8 hours and reports a 98%+ applicant rejection rate, with the top 2% accepted. For Q1 2026, RocketDevs reports a denominator of 14,233 applicants. These are RocketDevs' own figures and have not been independently audited, so they should be treated as self reported data.

The pricing is also published by developer level:

• Associate: $9.99/hr
• Mid senior: $21.99/hr
• Senior: $30.99/hr

That means the assessment and hiring decision can be evaluated against an actual published rate rather than a price you have to request.

The 14-day money-back trial is the part that most directly addresses the problem discussed in this article. It turns part of the hiring risk into a shorter trial period. Start with a vetted developer.

That matters because the biggest cost of a bad engineering hire is often not the salary. It is the amount of time the mistake occupies. A two week trial gives the startup an earlier opportunity to evaluate whether the developer is working out before committing to a much longer period.

It does not eliminate the risk. It changes how much of the risk the startup has to carry before it gets another decision point.

What to read next

The surrounding hiring decisions depend on what your startup needs.

If you are deciding how many engineers your seed funding can support, see How many engineers should a seed round buy?.

If you are deciding whether you need a founding engineer, see What is a founding engineer?.

For the economics of remote hiring, see What does it cost to hire a remote developer?.

If you are looking at the broader hiring process, see How to hire developers for a startup.

If the problem is management rather than engineering capacity, When should a startup hire its first engineering manager? is a different question with a different answer.

The broader lesson is simple: you cannot make a bad engineering hire risk free. You can make the risk smaller, measure it earlier and avoid letting one hiring decision consume an unreasonable share of your runway. Start with a vetted developer.

Conclusion

A bad engineering hire is not simply an expensive employee. At seed stage, the bigger cost is the time the mistake consumes.

The salary is easy to calculate. Employer costs can be added. Recruiting time can be measured. The harder costs are the months lost while the wrong person ramps up, the roadmap slips and someone else has to repair their work.

That is why there is no useful universal percentage for the cost of a bad hire. Your salary, location, runway and hiring process all change the calculation. More importantly, some of the largest costs still have no reliable published measurement.

The practical answer is to build your own model.

Start with the compensation you will actually pay. Add the employer costs. Price the hours your team will spend hiring and replacing the person. Then estimate how many months the decision could consume from your runway.

Once you know what is at stake, the case for structured vetting becomes much clearer.

You do not need an enormous hiring process. You need a process that gives you useful evidence before you make an expensive commitment. Define the work. Test relevant skills. Score candidates consistently. Set an early review point.

At seed stage, every hiring decision spends more than money. It spends time that the company may not get back.

The goal is not to eliminate hiring risk. It is to make sure one bad decision does not consume the runway you need to survive.

Frequently asked questions

How much does a bad hire cost? More than the widely quoted 30% of first year earnings, but there is no reliable way to calculate the full cost.

In US private industry, direct pay plus employer non wage costs comes to about 1.43 times gross salary, based on BLS data for March 2026. Recruiting costs come on top of that.

A bad hire can also consume time through ramp up, delayed product work and rework. Those costs are much harder to measure, and there is no published dataset that gives a reliable figure for them. Any total you calculate should therefore be treated as a floor rather than a complete estimate.

What percentage of new hires fail? There is no reliable independent dataset that gives a current failure rate for engineering hires.

A widely circulated figure comes from vendor research, but its sampling method is not sufficiently disclosed to use it as a dependable benchmark.

A more useful measure is your own hiring history. Look at your last 10 hires and ask how many were still delivering useful work six months after joining.

That is a small sample, but it reflects your company rather than an unsupported industry average.

How long does it take to replace an engineer? There is no current US statistic that provides a reliable answer.

The DHI DFH Mean Vacancy Duration Measure previously reported the average number of working days required to fill vacancies. The series was discontinued and last updated in February 2018.

Your own hiring data is therefore more useful. Measure the time from opening the role to the candidate accepting the offer. Then add the notice period they need to serve before they can start.

Is it cheaper to hire a contractor than a full time engineer? Often, when you look only at employer costs.

A full time employee comes with additional employer costs such as benefits. In US private industry, benefits represented 30.1% of total employer compensation costs in March 2026.

That does not automatically make a contractor cheaper. A contractor's hourly rate can include a significant margin, and the comparison also changes depending on how long you need the person and how much context they need to acquire.

Compare the fully loaded cost of employment with the contractor's actual rate. Comparing a salary directly with an hourly contract rate can give you the wrong answer.

How do you test an engineer before hiring them? Use a structured hiring process and a work sample that resembles the work they will actually do.

The selection literature consistently supports structured assessment over unstructured interviews. McDaniel and colleagues found that structured interviews had higher validity than unstructured interviews across data covering 86,311 individuals.

More recent work by Sackett and colleagues lowered many earlier validity estimates by 0.10 to 0.20 points after revisiting the statistical methods used in previous research. Structured interviews still ranked strongly after the correction.

For a practical process, give candidates the same core assessment, score them against the same rubric and have interviewers record their scores independently before discussing the candidate.

The goal is not to predict the future perfectly. It is to collect better evidence before committing months of runway to the hire.

Sources

• US Bureau of Labor Statistics, Employer Costs for Employee Compensation, March 2026, release USDL-26-0827, 12 June 2026. Read from the FRASER mirror hosted by the Federal Reserve Bank of St. Louis.
• US Bureau of Labor Statistics, Occupational Employment and Wage Statistics, 2025 estimates for SOC 15-1252, software developers.
• Eurostat, Labour cost levels by NACE Rev. 2 activity, dataset lc_lci_lev, information and communication sector, 2025.
• Gené Teare, news.crunchbase.com, Crunchbase News, 26 May 2026.
• Carta, Graduation rate from seed to Series A, Carta Data.
• Federal Reserve Bank of St. Louis, DHI-DFH Mean Vacancy Duration Measure by Industry: Information (DISCONTINUED).
• Frank L. Schmidt and John E. Hunter, The validity and utility of selection methods in personnel psychology, Psychological Bulletin, 1998.
• Paul R. Sackett, Charlene Zhang, Christopher M. Berry and Filip Lievens, Revisiting meta-analytic estimates of validity in personnel selection, Journal of Applied Psychology.
• Michael A. McDaniel, Deborah L. Whetzel, Frank L. Schmidt and Steven D. Maurer, The validity of employment interviews, Journal of Applied Psychology, 1994. 245 coefficients, 86,311 individuals.
• METR, metr.org, 10 July 2025.
• Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng and Tobias Salz, The effects of generative AI on high-skilled work, Management Science. Three field experiments, 4,867 developers.
• Levels.fyi software engineer compensation, self-reported total compensation, read 25 August 2026.

James Hitch, COO at RocketDevs. Connect on LinkedIn.